Notas para quienes desarrollan con inteligencia artificial: cómo funcionan los modelos, cómo usarlos en un producto y cómo evaluar lo que hacen.
Qué errores son esperables en un sistema con IA, quién responde por ellos y qué prácticas ayudan a trabajar con responsabilidad frente al cliente.
Lo que suele faltar entre una demo que impresiona y un sistema con IA que se puede ofrecer a clientes: errores, límites, trazabilidad y soporte.
Qué cambia al ajustar un modelo con tus propios datos, qué necesitás para hacerlo bien y qué alternativas probar primero.
Criterios para decidir qué información puede salir de tu sistema hacia un proveedor de modelos y cómo reducir la exposición.
De qué depende el costo de usar un modelo, cómo estimarlo antes de lanzar y qué decisiones lo bajan sin degradar el resultado.
Armar un conjunto de casos de prueba, definir qué es una buena respuesta y detectar regresiones cuando cambia el modelo o el prompt.
Usos prácticos de un modelo para documentar y revisar código, y los límites que conviene tener claros antes de confiar en el resultado.
Cómo aprovechar un modelo para escribir pruebas y casos borde sin terminar con tests que solo confirman lo que el código ya hace.
Qué tareas conviene delegar a un asistente, cuáles revisar con más cuidado y cómo evitar que el código generado te complique el proyecto.
Qué son los embeddings, para qué sirve una base vectorial y por qué muchas veces una búsqueda de texto tradicional resuelve el problema.
Qué es la generación aumentada por recuperación, cómo se arma el flujo y dónde suele fallar en la práctica.
Qué hay que resolver al llamar a la API de un modelo desde una aplicación: claves, errores, tiempos de espera y salidas estructuradas.
Cómo escribir instrucciones claras para un modelo, probarlas con ejemplos reales y mantenerlas como se mantiene el código.
Tokens, contexto y predicción del próximo fragmento: lo mínimo que conviene entender para usar un modelo sin sorpresas.
Una explicación sin humo de qué puede hacer hoy la IA en el trabajo de un desarrollador y dónde sigue necesitando a una persona.
Notas sobre las fallas de seguridad más comunes en aplicaciones, cómo se previenen y cómo se detectan, escritas para quienes desarrollan.
El informe es el comienzo: cómo organizar las correcciones, verificar que funcionaron y evitar que los mismos problemas vuelvan.
Almacenamiento público, permisos excesivos y servicios expuestos: los descuidos de configuración que más se repiten en entornos cloud.
Qué contiene un buen informe, cómo interpretar la gravedad de cada hallazgo y en qué orden conviene corregir.
Un repaso de las cabeceras que endurecen un sitio web, para qué sirve cada una y los errores al activarlas.
Cada librería que instalás es código ajeno que corre con tus permisos: cómo mantener el inventario y reaccionar a las vulnerabilidades publicadas.
Claves y contraseñas que terminan en el historial de git: cómo ocurre, cómo detectarlo y qué hacer cuando ya pasó.
Autorización, exposición excesiva de datos, falta de límites y validación: una lista práctica para revisar una API antes de publicarla.
Autorización a nivel de objeto y de función: por qué es de los fallos más frecuentes y cómo diseñarla para que no dependa de la memoria de cada desarrollador.
Contraseñas, recuperación de cuentas, tokens y cierre de sesión: dónde se equivoca la mayoría y qué revisar en tu sistema.
Cómo un sitio termina ejecutando código de un tercero en el navegador de sus usuarios y qué hacer para evitarlo.
Por qué concatenar texto en una consulta abre la puerta a la inyección y cómo las consultas parametrizadas la cierran.
Un recorrido por las categorías de riesgo que más se repiten en aplicaciones web y qué hábito de desarrollo previene cada una.
Qué se define antes de la primera prueba: sistemas incluidos, ventanas de tiempo, datos permitidos y a quién avisar si algo sale mal.
Momentos razonables para contratar una prueba de seguridad y señales de que primero hay que ordenar lo básico.
Una prueba de penetración combina herramientas y criterio humano para demostrar qué puede lograr un atacante. Acá, cómo se distingue de un escáner automático.