- Tutorial de interrogación de IA: Utiliza preguntas estructuradas para revelar comportamientos inseguros, engañosos o confidenciales del modelo.
- Flujo de trabajo principal: Delimita los riesgos, diseña las pruebas, ejecútalas de forma segura, clasifica los fallos y repite las evaluaciones.
- Métodos fundamentales: Combina sondeos mediante prompts, entradas adversarias, preguntas socráticas y ejercicios de red teaming.
- Mejor práctica: Registra los prompts, las respuestas, el contexto y las evidencias de remediación para permitir revisiones trazables.
- Límite de seguridad: Realiza las pruebas en entornos controlados, con datos aprobados, planes de reversión y responsabilidades claramente asignadas.
Tutorial de interrogación de IA: propósito y alcance
Un tutorial de interrogación de IA debe comenzar con un objetivo defensivo: descubrir dónde falla un sistema de IA antes de que esos fallos se conviertan en incidentes visibles para los usuarios. La interrogación de IA es una práctica amplia que consiste en consultar, someter a presión y analizar intencionadamente el comportamiento de un modelo. Puede revelar alucinaciones, filtraciones de privacidad, seguimiento malicioso de instrucciones, razonamientos inconsistentes y límites de seguridad débiles.
Este trabajo forma parte de un programa más amplio de supervisión, seguridad y gobernanza de la IA. No se trata simplemente de reunir prompts ingeniosos. Una campaña útil conecta los objetivos de las pruebas con los activos, los escenarios de usuario, los perfiles de los atacantes, la sensibilidad de los datos y las tareas de remediación medibles.
| Área de riesgo | Qué examinar | Ejemplo de evidencia |
|---|---|---|
| Seguridad y protección | Respuestas dañinas o que infringen políticas | Prompt, respuesta, categoría de la política |
| Privacidad | Divulgación de datos confidenciales o personales | Traza anonimizada, clasificación de datos |
| Seguridad informática | Inyección de prompts o elusión de instrucciones | Ruta del ataque, flujo de trabajo afectado |
| Fiabilidad | Alucinaciones y respuestas inconsistentes | Respuestas repetidas, resultado de verificación de hechos |
| Gobernanza | Falta de responsables o registros de auditoría | ID de prueba, revisor, estado de remediación |
Comienza definiendo qué puede hacer el sistema, a qué información puede acceder y qué resultados causarían un daño inaceptable. Esto evita realizar pruebas sin un objetivo claro y proporciona a los revisores un criterio coherente para determinar la gravedad.
Descubrimiento de la superficie de ataque
Identifica cómo los usuarios, el contenido recuperado, las herramientas o los cambios de contexto podrían manipular el modelo o exponer información restringida.
Resiliencia de seguridad
Simula comportamientos adversarios realistas para que los equipos puedan reforzar las defensas antes de que las debilidades sean explotadas en producción.
Supervisión auditable
Conserva los casos de prueba, las trazas, las decisiones y las correcciones para que los revisores futuros puedan verificar qué cambió y por qué.
Define los activos, permisos, clases de datos y escenarios de usuario antes de escribir prompts adversarios. Un modelo de amenazas limitado produce resultados más útiles que los sondeos aleatorios.
Técnicas fundamentales de interrogación de IA
La interrogación de IA funciona mejor cuando se combinan varios estilos de prueba. Los generadores automatizados pueden abarcar grandes colecciones de prompts, mientras que los revisores humanos aportan contexto, creatividad y criterio. Cada técnica debe tener un propósito definido y un formato de registro.
| Técnica | Propósito principal | Enfoque útil |
|---|---|---|
| Sondeo basado en prompts | Encontrar respuestas inseguras, inexactas o confidenciales | Role-play, cambios de contexto, prompts iterativos |
| Pruebas de jailbreak | Evaluar la resistencia a intentos de eludir las barreras de seguridad | Persuasión, conflictos de instrucciones, ofuscación |
| Red teaming | Simular amenazas coordinadas del mundo real | Debilidades del modelo, del producto, de la seguridad y de las políticas |
| Entradas adversarias | Forzar casos límite y comportamientos inesperados | Texto ofuscado, formatos inusuales, contexto contaminado |
| Preguntas socráticas | Revelar suposiciones ocultas y contradicciones | Preguntas de seguimiento por capas, comprobación de evidencias, coherencia |
El sondeo basado en prompts utiliza conjuntos de pruebas repetibles en lugar de preguntas aisladas. Comienza con solicitudes normales y, a continuación, introduce casos límite y variaciones adversarias controladas. Compara cómo responde el modelo cuando cambian la redacción, el rol, el contexto o el historial de la conversación.
Las pruebas de jailbreak e ingeniería social analizan si la persuasión o el encuadre pueden hacer que un sistema ignore sus restricciones. Estas pruebas deben estar autorizadas y ejecutarse en un entorno aislado. El objetivo es medir el límite, no desplegar una elusión contra usuarios reales o sistemas sensibles.
El red teaming de IA amplía la perspectiva más allá de la redacción de los prompts. Los evaluadores de distintas áreas pueden revisar las suposiciones del entrenamiento, las herramientas en tiempo de ejecución, las fuentes de recuperación, los controles de acceso y el comportamiento de la interfaz de usuario. El red teaming es un método estructurado dentro de la disciplina más amplia de la interrogación de IA.
Las preguntas socráticas son especialmente útiles para las revisiones de fiabilidad. Pide al sistema que exponga sus suposiciones, identifique las evidencias, explique la incertidumbre y reconsidere su conclusión después de recibir información nueva. Esto puede revelar contradicciones que una única respuesta ocultaría.
No ejecutes pruebas adversarias contra sistemas de producción sin aprobación por escrito, supervisión y procedimientos de monitorización y reversión. Nunca incluyas secretos reales ni datos personales innecesarios en los prompts de prueba.
Flujo de trabajo de interrogación de IA paso a paso
Un flujo de trabajo repetible convierte los hallazgos de la interrogación en acciones de ingeniería y gobernanza. Las cinco etapas siguientes reflejan un ciclo de vida práctico: definir la amenaza, crear las pruebas, recopilar evidencias, corregir los problemas prioritarios y verificar el resultado.
Define el modelo de amenazas
Enumera los activos protegidos, los datos sensibles, los grupos de usuarios, las herramientas conectadas y los comportamientos probables de los atacantes. Establece qué se considera una filtración crítica, una respuesta insegura, un fallo de seguridad o una alucinación inaceptable.
Diseña el conjunto de pruebas
Crea prompts normales, de casos límite y adversarios. Añade guiones de escenarios para cambios de rol, modificaciones iterativas del contexto, inyección de prompts, solicitudes de privacidad e instrucciones contradictorias.
Ejecuta y registra
Ejecuta las pruebas en un entorno controlado. Registra la secuencia completa de prompts, la salida del modelo, el contexto del sistema, la configuración, la marca de tiempo, el evaluador y cualquier actividad de herramientas o recuperación.
Clasifica y remedia
Clasifica cada fallo como relacionado con la seguridad y protección, la privacidad, la seguridad informática, las alucinaciones o la gobernanza. Prioriza las correcciones según el impacto en los usuarios, la sensibilidad de los datos, la facilidad de explotación y la recurrencia.
Cierra el ciclo
Vuelve a ejecutar los casos fallidos, añade pruebas de regresión, supervisa el comportamiento en producción y conecta los resultados con las revisiones de lanzamiento, los procesos de gobernanza y las puertas de evaluación de CI/CD.
| Etapa del flujo de trabajo | Resultado requerido | Pregunta de revisión |
|---|---|---|
| Alcance | Modelo de amenazas y límites de las pruebas | ¿Qué debe proteger el sistema? |
| Diseño | Conjunto versionado de prompts y escenarios | ¿Las pruebas cubren el uso normal y adversario? |
| Ejecución | Registros y trazas reproducibles | ¿Otro revisor puede reproducir el resultado? |
| Clasificación | Asignación de gravedad y responsable | ¿Qué fallos requieren una acción inmediata? |
| Cierre del ciclo | Evidencia de regresión y plan de monitorización | ¿La corrección mejoró el comportamiento sin introducir nuevos riesgos? |
La etapa de ejecución debe conservar suficiente contexto para que el resultado sea significativo. Una respuesta puede parecer segura de forma aislada, pero fallar cuando el modelo recibe texto recuperado, una instrucción del sistema modificada o un historial de conversación más largo. Por ello, la trazabilidad es tan importante como el propio prompt.
Un hallazgo sólido incluye el caso de prueba, el comportamiento observado, el impacto, la gravedad, el responsable, la corrección recomendada y el resultado de la verificación. Esto hace que la interrogación sea útil tanto para los equipos técnicos como para los de gobernanza.
Registro, clasificación y remediación
La interrogación fiable de IA depende de las evidencias. El registro debe favorecer la auditabilidad sin recopilar más información sensible de la necesaria. Cuando los datos de prueba contienen material personal o confidencial, utiliza ejemplos sintéticos o anonimizados aprobados siempre que sea posible.
| Tipo de hallazgo | Indicadores de prioridad | Respuesta habitual |
|---|---|---|
| Filtración crítica de privacidad | Divulgación de secretos o datos restringidos | Revocar la vía de exposición, investigar el acceso y añadir pruebas de regresión |
| Salida maliciosa | Instrucciones dañinas o asistencia insegura | Revisar los controles de las políticas, los filtros, el comportamiento del modelo y la escalación |
| Elusión de seguridad | Las instrucciones anulan los controles previstos | Inspeccionar la jerarquía, los permisos de las herramientas y los límites de recuperación |
| Alucinación | Afirmación segura de sí misma sin respaldo | Mejorar la fundamentación, el tratamiento de la incertidumbre y la verificación de hechos |
| Inconsistencia | Respuestas materialmente distintas ante prompts equivalentes | Añadir pruebas de variación y revisar la estabilidad del modelo o del contexto |
La clasificación debe tener en cuenta algo más que la frecuencia. Un fallo poco frecuente que implique datos muy sensibles puede requerir una acción más rápida que un problema habitual de formato y bajo impacto. Entre los factores útiles para establecer prioridades se incluyen:
- Impacto en los usuarios: ¿Podría el resultado perjudicar a una persona, un cliente o una organización?
- Sensibilidad de los datos: ¿La salida revela información personal, confidencial o regulada?
- Facilidad de explotación: ¿Un usuario habitual puede reproducir el comportamiento?
- Alcance: ¿El problema afecta a un flujo de trabajo o a muchos despliegues?
- Persistencia: ¿El fallo permanece después de cambiar el modelo, el prompt o la configuración?
La remediación puede incluir restricciones más estrictas en los prompts, filtrado de salidas, mejores controles de recuperación, restricciones de acceso, actualizaciones del modelo, revisión humana o mensajes de producto más claros. Evita considerar una única repetición exitosa de la prueba como prueba de que el problema está resuelto. Vuelve a ejecutar variaciones cercanas al fallo original y añade el caso a un conjunto permanente de pruebas de regresión.
Registra la traza
Captura la interacción completa, el contexto relevante, la configuración, las notas del evaluador y la actividad de las herramientas, minimizando al mismo tiempo los datos sensibles.
Clasifica el riesgo
Prioriza según el impacto, la sensibilidad, la facilidad de explotación, el alcance y la persistencia, en lugar de limitarte a contar los fallos.
Verifica la corrección
Vuelve a ejecutar el caso original y las variaciones cercanas, y registra si la mitigación produjo nuevos cambios de comportamiento.
La guía de referencia sobre interrogación de IA describe las pruebas continuas, la evaluación automatizada y humana combinada, un registro sólido y la remediación basada en riesgos como prácticas fundamentales. Trata estas prácticas como un ritmo operativo y no como una auditoría única.
Utiliza identificadores de prueba estables, prompts versionados, marcas de tiempo y revisores identificados. Los registros claros ayudan a los equipos a comparar lanzamientos y demostrar que las correcciones se probaron realmente.
Lista de comprobación de la campaña y estándares prácticos
Utiliza la lista de comprobación siguiente antes de cerrar una campaña de interrogación. Está diseñada tanto para las evaluaciones iniciales como para las revisiones periódicas de lanzamientos.
Lista de comprobación de preparación de la campaña:
- Define los activos protegidos, los datos sensibles, los escenarios de usuario y los perfiles de los atacantes
- Crea conjuntos de prompts normales, de casos límite, adversarios y de regresión
- Ejecuta las pruebas en un entorno aislado con datos aprobados y procedimientos de reversión
- Registra los prompts, las salidas, el contexto, la configuración, las herramientas, las marcas de tiempo y los revisores
- Asigna la gravedad, el responsable, la remediación y el estado de verificación a cada hallazgo
| Estándar | Práctica recomendada | Señal de advertencia |
|---|---|---|
| Continuidad | Realiza pruebas en los lanzamientos principales y de forma periódica en sistemas de alto riesgo | La evaluación solo se realiza después de un incidente |
| Cobertura | Combina automatización, red teams humanos y preguntas estructuradas | Las pruebas dependen de una sola categoría de prompts |
| Trazabilidad | Conserva evidencias versionadas y registros de remediación | Los resultados no se pueden reproducir |
| Priorización | Clasifica según el impacto y la sensibilidad de los datos | Todos los fallos reciben la misma respuesta |
| Integración | Conecta los hallazgos con la monitorización, la gobernanza y CI/CD | Las correcciones no se comprueban en lanzamientos futuros |
Una campaña está lista para cerrarse cuando los hallazgos de alta prioridad tienen responsables, las mitigaciones se han verificado y los riesgos restantes están documentados. La monitorización continua sigue siendo importante porque el comportamiento del modelo puede cambiar cuando cambian los prompts, los datos de recuperación, las herramientas, las políticas o las versiones del modelo.
Guarda los fallos representativos como pruebas reutilizables. Una biblioteca de regresión en crecimiento evita que los equipos tengan que resolver repetidamente la misma debilidad y agiliza las comparaciones entre lanzamientos.
Preguntas frecuentes sobre la interrogación de IA
Q: ¿Qué es la interrogación de IA?
La interrogación de IA es la práctica defensiva de consultar, persuadir y someter intencionadamente a pruebas de estrés a los sistemas de IA para encontrar fallos como alucinaciones, filtraciones de privacidad, salidas inseguras y elusión de instrucciones.
Q: ¿En qué se diferencia la interrogación de IA del red teaming?
La interrogación de IA es la disciplina más amplia de analizar el comportamiento de los modelos. El red teaming es un enfoque estructurado dentro de ella que normalmente involucra a expertos de distintas áreas para simular amenazas adversarias.
Q: ¿La interrogación puede dañar un modelo de IA?
Las pruebas realizadas correctamente en un entorno aislado no deberían dañar el modelo. Utiliza entornos controlados, entradas aprobadas, monitorización y procedimientos de reversión para que los experimentos permanezcan separados del comportamiento en producción.
Q: ¿Con qué frecuencia deben realizar los equipos estas pruebas?
Las pruebas deben ser continuas durante todo el ciclo de vida del modelo. Repite las evaluaciones después de los lanzamientos principales y considera revisiones periódicas para aplicaciones de alto riesgo, especialmente cuando cambien las herramientas, los prompts, las políticas o las fuentes de datos.
No publiques detalles de explotación, trazas confidenciales ni datos personales en informes públicos. Comparte los hallazgos a través de los canales de seguridad y gobernanza aprobados por la organización.