Cinco preguntas antes de poner en marcha un sistema de IA

Su equipo quiere poner un sistema de IA en producción. La demostración funcionó, el caso de negocio se ve bien y todos están entusiasmados. Antes de dar el visto bueno, estas cinco preguntas le dirán más sobre el riesgo que cualquier presentación.

No necesita ser técnico para hacerlas. Sí necesita escuchar respuestas claras.

1. ¿De qué datos aprende y quién puede modificarlos?

Los modelos de IA aprenden de los datos, y muchos siguen adaptándose a medida que llegan datos nuevos. Eso es lo que los hace útiles; también es lo que los diferencia del software tradicional. Si alguien puede manipular los datos de entrenamiento o de referencia, puede influir en cómo se comporta el modelo. Eso se llama envenenamiento de datos (data poisoning). En salud podría significar una mala decisión sobre un paciente; en finanzas o logística podría sesgar silenciosamente decisiones que parecen completamente rutinarias.

Pregunte de dónde vienen los datos, quién puede escribir en ellos y cómo se verifica su calidad.

2. ¿Quién puede acceder al modelo y qué puede obtener de él?

Un modelo es un activo. Los atacantes intentan copiarlo (robo de modelos), sondearlo o alimentarlo con entradas diseñadas para que falle (ataques adversarios). Si el sistema usa un modelo de lenguaje de gran tamaño (LLM), agregue la inyección de instrucciones (prompt injection) a la lista: instrucciones ocultas en un documento o página web que el modelo sigue como si vinieran de usted.

Pregunte quién tiene acceso al modelo, a sus resultados y a todo aquello sobre lo que puede actuar. Si la respuesta es "el equipo que lo construyó", siga preguntando.

3. ¿Cómo sabríamos si empezara a comportarse mal?

Los sistemas tradicionales suelen fallar de forma evidente. Los sistemas de IA pueden fallar en silencio; los resultados siguen pareciendo razonables, simplemente están equivocados. El monitoreo debe vigilar desviaciones, resultados extraños y usos inusuales, no solo la disponibilidad.

Pregunte quién está vigilando, qué está vigilando y qué tan rápido detectaría un problema antes que un cliente.

4. ¿Participó seguridad en el diseño, o solo en la revisión?

Corregir una brecha de seguridad después del lanzamiento cuesta más que diseñar para evitarla. Es la misma lección que aprendimos con el software hace décadas, y aquí también aplica. El OWASP AI Exchange insiste en este punto: integre la seguridad en el ciclo de desarrollo de la IA desde el principio, no como un control final.

Pregunte cuándo vio seguridad este proyecto por primera vez y qué cambió como resultado.

5. ¿Quién es dueño del riesgo una vez que está en producción?

Esta es la que suele provocar la pausa más larga. Alguien tiene que "ser dueño del riesgo" después del lanzamiento; una persona con nombre, no un comité. Esa persona decide qué se monitorea, cuándo se reentrena el modelo y cuándo se apaga.

Pida un nombre. Si no lo hay, ya encontró su primera tarea.

En resumen

Si su equipo puede responder las cinco con claridad, va por buen camino. Si dos o tres reciben un encogimiento de hombros, no es motivo para cancelar el proyecto; es motivo para frenar un par de semanas y obtener las respuestas. Tenga el plan listo y luego ejecútelo.

Si quiere una segunda opinión antes de su próxima aprobación de IA, ofrezco una llamada de diagnóstico gratuita de 30 minutos para organizaciones que califiquen. Reserve un horario aquí.

Dan Sorensen es líder en ciberseguridad, colaborador del Forbes Technology Council, miembro del equipo central del OWASP AI Exchange y CISO fraccional.