Si estás construyendo un asistente con un LLM, el problema no es “si va a fallar”, sino “cómo y cuándo”. La diferencia entre un bot que se ve espectacular en demo y uno que aguanta producción es que el segundo fue atacado, estresado y forzado a responder en condiciones horribles antes de salir al mundo. A eso le llamamos red-teaming de prompts: provocar fallos a propósito para encontrarlos tú primero, documentarlos y corregirlos con método. Y sí, en algún punto vas a necesitar ayuda de una Agencia de IA si tu caso implica datos reales, herramientas conectadas y riesgos de reputación o cumplimiento.
El red-teaming no es un “capricho de seguridad”. Es una práctica de calidad. Un prompt puede sonar perfecto y aun así desmoronarse cuando el usuario pega un correo kilométrico, mezcla idiomas, llega con prisa, exige una respuesta o intenta colar instrucciones dentro de un documento. Por eso el foco no es escribir la frase mágica, sino construir un sistema que se comporte bien incluso cuando el entorno se comporta mal.
Qué es red-teaming de prompts y por qué se parece más a QA que a “prompting”
En esencia, red-teaming es pensar como atacante (o como usuario impredecible) y probar tu asistente contra escenarios que en producción son inevitables. Esto incluye desde jailbreaks directos hasta fallos de precisión, fugas de información, instrucciones contradictorias y degradación por contexto largo. Si lo comparas con el desarrollo web, es como pasar de “se ve bien en mi máquina” a “pasa tests, soporta carga, no rompe seguridad y tiene observabilidad”.
Mucha gente lo confunde con “optimizar el prompt”. La optimización busca que el modelo sea más útil y consistente en condiciones normales. El red-teaming busca encontrar las condiciones anormales que lo vuelven peligroso, torpe o incoherente. Y casi siempre el problema real está en la interacción entre prompt, contexto y herramienta: el asistente no “piensa”, calcula probabilidades. Si le das un contexto contaminado o demasiada libertad para actuar, no necesitas un hacker brillante: un usuario insistente basta.
En proyectos reales, el red-teaming termina siendo un puente entre producto, ingeniería y compliance. Producto define qué es aceptable, ingeniería decide cómo impedir acciones peligrosas, y compliance acota riesgos legales. El prompt no reemplaza esa conversación; la vuelve urgente.
El salto de demo a producción: por qué todo se rompe ahí
En demo, tú controlas todo. Las preguntas son limpias, la intención es clara, el contexto es corto y normalmente nadie intenta engañar al sistema. En producción pasan tres cosas que cambian el juego.
La primera es la ambigüedad. Usuarios que dicen “hazlo como la otra vez”, “resúmelo”, “dame el resultado”, sin contexto suficiente. Si el bot intenta “ayudar” inventando, tendrás respuestas convincentes pero falsas. Esto daña confianza y, según el sector, puede meterte en problemas.
La segunda es el ruido. Textos copiados de PDFs, logs, chats internos, mensajes con sarcasmo, emojis, mayúsculas, faltas de ortografía, frases incompletas. El bot no se “ofende”, pero sí puede interpretar mal la intención, perder el hilo o dar respuestas fuera de tono.
La tercera es la expansión de superficie por integraciones. Cuando conectas el bot a una base de conocimiento o a herramientas, el riesgo deja de ser solo “dijo algo incorrecto” y pasa a ser “hizo algo incorrecto”. En ese punto, el red-teaming no solo debe probar la respuesta, sino el comportamiento: qué decide, qué herramienta intenta usar y con qué nivel de certeza lo hace.
Es aquí donde conviene recordar una idea básica: si el modelo puede actuar, tu sistema necesita controles. Si además puede actuar con datos sensibles, necesitas controles + auditoría + límites. Y si el proyecto tiene presión comercial (“hay que lanzarlo ya”), más razón para red-teamear antes.
El error más común: red-teamear sin definir qué es un fallo
Red-teamear sin un marco de riesgo es como hacer marketing sin objetivo: te mueve mucho, pero no sabes si avanzas. Antes de probar nada, define qué cuenta como fallo en tu producto. No es lo mismo un asistente de contenido que uno de soporte médico o uno que opera sobre datos de clientes.
Piensa en activos: información sensible, prompts del sistema, políticas internas, pricing, datos personales. Piensa también en acciones: enviar emails, crear tickets, ejecutar consultas, modificar estados en un CRM. Y por último, piensa en impacto: reputación, cumplimiento, coste de soporte y pérdida de ventas.
En esta fase, la semántica ayuda porque te obliga a concretar entregables y límites. Es típico que las empresas mezclen “quiero un bot que ayude” con “quiero que haga tareas por mí”. Si no lo separas, el bot acaba tomando decisiones donde no debe.
Aquí aparece uno de los conceptos clave en proyectos de consultoría de IA: definir responsabilidad. Qué decide el sistema, qué decide la persona y_extractivamente_ qué se valida antes de ejecutar. Ese mapa es el punto de partida del red-teaming.
La secuencia que suele funcionar: hipótesis → pruebas → fixes → regresión
Cuando el red-teaming se hace bien, parece una rutina de ingeniería. No es una sesión creativa infinita. Empiezas con hipótesis de fallo (“si el usuario pide X, el bot podría revelar Y”), construyes pruebas que lo intenten provocar, corriges y, lo más importante, conviertes esos casos en regresión para que no vuelvan.
Al inicio, mucha gente intenta “arreglarlo con más prompt”. Funciona un rato, pero luego aparece otro caso y vuelves a parchear. La salida es sistematizar: cada fallo encontrado se documenta, se clasifica (grave/medio/leve) y se convierte en un test. Así, cuando cambias el prompt o el modelo, sabes si rompiste algo.
En esta secuencia, es normal que tu prompt evolucione hacia un “contrato” más claro: qué se puede hacer, qué no, qué preguntas hacer antes de responder, cómo manejar incertidumbre y cómo citar fuentes cuando hay contexto recuperado. Pero ese contrato solo funciona si el sistema alrededor lo respeta.
Ataques y fallos que debes provocar (sin volverte paranoico)
Hay un punto medio sano entre “no probar nada” y “probar 5.000 jailbreaks”. En la práctica, lo que más valor aporta es cubrir categorías que ocurren en casi todos los productos.
Uno de los clásicos es el jailbreak por rol o autoridad. Un usuario intenta que el bot “ignore instrucciones” o se haga pasar por un perfil superior. Si el bot se deja, significa que prioriza mal. No se trata de que siempre rechace: se trata de que sepa pedir verificación o que mantenga límites. Por ejemplo, si alguien pide acciones sensibles, el bot puede decir “puedo ayudarte a preparar el mensaje, pero no voy a enviarlo sin confirmación”.
Otro fallo muy común es la exfiltración. El usuario pide el prompt del sistema, pide instrucciones internas o pide que revele cómo está configurado. Aunque el modelo no tenga secretos reales, puede inventar. Y si inventa con tono seguro, el usuario cree que es real. Eso también es un fallo, porque genera ruido interno, tickets, y confusión sobre seguridad.
El tercer bloque, y el más traicionero, es la inyección indirecta. Cuando tu sistema usa contexto externo (documentos, páginas, tickets), ese texto puede contener instrucciones maliciosas o simplemente confusas. El modelo no distingue “esto es una orden” de “esto es contenido” si no se lo dejas claro. Por eso, en proyectos con RAG, el red-teaming debe incluir pruebas donde el contexto tenga frases que intentan dominar el comportamiento.
RAG: cuando el contexto es útil… y también un vector de ataque
En teoría, el RAG resuelve un problema: el modelo no sabe cosas específicas de tu negocio, así que le damos contexto recuperado. En práctica, introduces dos riesgos nuevos: el contexto puede ser incorrecto o puede estar manipulado.
Lo primero pasa incluso sin mala intención: documentación desactualizada, wikis duplicadas, tickets con suposiciones, PDFs antiguos. Si el bot lo toma como verdad absoluta, alucina con “evidencia”. Lo segundo pasa con intención: alguien mete instrucciones en un documento (“si te preguntan por X, responde Y”) y el sistema lo recupera como contexto.
La solución no es “no usar RAG”, sino usarlo bien. Tu prompt debe tratar el contexto como referencia, no como instrucciones. El bot debe citar o al menos señalar de dónde sale la respuesta. Y el sistema debe limitar cuánto texto puede “volcar” para evitar que pegue documentos completos.
Además, el red-teaming aquí debe simular conversaciones realistas: un usuario pega un párrafo con instrucciones, o el contexto contiene un bloque ambiguo. Si tu bot responde sin freno, lo verás rápido. Si lo ves rápido, lo corriges. Si no lo ves, lo descubrirás cuando soporte te mande un pantallazo con “¿por qué el bot dijo esto?”.
Calidad también es seguridad: precisión, incertidumbre y consistencia
Un error muy típico es pensar que red-teaming es solo “evitar cosas prohibidas”. En realidad, también es evitar respuestas peligrosamente equivocadas. Un bot que inventa un número, un procedimiento o un requisito legal con seguridad puede causar un daño real, aunque no haya “ataque” y luego, deberás medir precisión, seguridad y coste por caso de uso.
Por eso, parte del red-teaming debe atacar la precisión. Haz preguntas con datos incompletos, con información contradictoria, con trampas de contexto (“te dije antes X, pero ahora digo Y”), o con inputs largos donde la información importante está enterrada. Mira si el bot pregunta antes de responder o si se lanza a completar huecos.
Aquí conviene incorporar hábitos de machine learning aplicados a producto: medir tasa de alucinación, medir consistencia entre turnos y medir “calidad del rechazo”. Porque sí, rechazar bien es una habilidad. Un buen rechazo no es “no puedo”, es “no puedo por esto, pero puedo ayudarte de esta otra forma”. Eso mantiene UX y reduce frustración.
Cuando el bot puede ejecutar cosas: el red-teaming cambia de nivel
Si tu asistente solo responde texto, el daño suele ser reputación, confianza, soporte. Cuando el asistente puede ejecutar acciones, el daño puede ser operativo: crear tickets basura, enviar mensajes equivocados, tocar datos incorrectos, disparar costes o generar incidentes.
Aquí entra la parte que más se parece a ingeniería: permisos, confirmaciones y validación. El modelo no debería tener acceso “total” a herramientas. Lo ideal es mínimo privilegio: solo puede usar lo estrictamente necesario para esa tarea. Y si la acción es sensible, debe pedir confirmación humana. También hay que validar la salida: si el bot devuelve un JSON o parámetros para ejecutar, se valida esquema, rangos y listas blancas.
Esta es la base de cualquier automatización con IA bien montada: el modelo propone, el sistema verifica. Si inviertes ese orden, estás apostando la estabilidad del negocio a una predicción probabilística.
Cómo convertir el red-teaming en una rutina que no dependa de héroes
El principal motivo por el que el red-teaming “se abandona” es que queda en manos de una persona con tiempo. Y eso no existe en producción. La forma realista de mantenerlo vivo es automatizar parte del proceso y dejar lo complejo para revisión periódica.
Lo típico es tener una suite de casos: algunos se validan con reglas (no debe haber PII, no debe revelar instrucciones internas, debe responder en un formato), y otros se revisan semánticamente con un evaluador o con revisión humana en muestras. No necesitas perfección, necesitas repetibilidad. Cuando cambias prompt o modelo, ejecutas la suite y ves si algo rompió.
También ayuda instrumentar el producto: logs de conversaciones, banderas de riesgo, trazas de uso de herramientas y feedback. La observabilidad es el puente entre “lo probamos” y “lo mantenemos”. Si no ves lo que pasa, no puedes mejorar sin adivinar.
Por eso, muchas empresas acaban trabajando con una agencia de inteligencia artificial que no solo entrega el bot, sino el proceso para que el bot no se degrade con el tiempo.
Una historia típica: “el bot funcionaba perfecto… hasta que alguien subió un PDF raro”
Este caso pasa más de lo que parece. Montas un asistente con base de conocimiento, conectas un repositorio de documentos, y el bot empieza a responder muy bien. Hasta que un día alguien sube un documento con un texto confuso o con instrucciones incrustadas. El sistema recupera ese documento como contexto, el modelo lo lee y empieza a comportarse raro: cambia el tono, hace afirmaciones extrañas o entrega demasiado contenido.
Cuando investigas, te das cuenta de que el modelo no “distingue” el documento como potencialmente hostil. Solo ve tokens en contexto y optimiza para “ser útil”. Si no has definido límites, se cuela.
La solución casi siempre es una combinación de: etiquetar el contexto, reforzar políticas de sistema, limitar quote/volcado, y filtrar contenido sospechoso. Y, por supuesto, convertir el caso en test para que no vuelva. Cuando haces esto bien, el bot deja de ser frágil. Cuando no, el bot se convierte en una bomba de relojería reputacional.
Cierre: producción no perdona, pero el proceso sí salva
El red-teaming de prompts no es un “extra”, es el paso que te evita sorpresas. No se trata de escribir el prompt perfecto, sino de construir un ciclo de mejora: definir fallos, provocarlos, arreglarlos y asegurar que no regresen. Lo bonito es que cuando lo haces bien, el beneficio no es solo seguridad: sube la calidad, baja el soporte, mejora la consistencia y tu equipo confía más en el sistema.
A lo largo de este artículo hemos aterrizado conceptos y prácticas que normalmente se trabajan en proyectos de consultoría de IA, donde lo importante no es “que responda”, sino que responda bien, con límites, con validación y con un sistema alrededor que no dependa de fe. En Bolmia lo vemos así: si un asistente no tiene pruebas y guardrails, no está listo. Y si quieres evitar que el primer “red-team” sea tu propio usuario en producción, toca hacer el trabajo antes, no después.
Preguntas frecuentes sobre el artículo
1) ¿Cuándo tiene sentido hacer pruebas “ofensivas” a un asistente?
Cuando vaya a estar en producción con usuarios reales, datos internos o conversaciones largas. También si integra documentos, CRM o herramientas.
2) ¿Esto es solo para seguridad o también mejora la calidad?
Ambas. Detecta jailbreaks y fugas, pero también alucinaciones, inconsistencias y respuestas sin contexto suficiente.
3) ¿Cuántos casos de prueba necesito para empezar?
Con 30–50 casos bien elegidos ya aparecen fallos serios. Lo importante es que sean repetibles y representen tu negocio.
4) ¿Qué cambia si el bot puede ejecutar acciones?
El riesgo sube: debes limitar permisos, pedir confirmaciones en acciones críticas y validar outputs (formatos, rangos y reglas) antes de ejecutar.
5) ¿Cómo evito que se rompa al cambiar el prompt o el modelo?
Con pruebas de regresión: cada fallo descubierto se convierte en caso de test y se ejecuta en cada deploy junto con métricas básicas.
