Seguridad en IA: el riesgo real no es el que crees

El miedo equivocado

Cuando hablo de seguridad de IA con una dirección, casi siempre aparece la misma pregunta: ¿y si el modelo se vuelve autónomo y se sale de control? Es la pregunta de las películas. No es la que le va a costar plata a la empresa este trimestre.

La tensión es esta: la empresa vigila un riesgo de ciencia ficción mientras deja tres puertas abiertas de par en par. La fuga de datos por el uso diario. Las decisiones sin dueño, donde nadie responde por el resultado. La dependencia total de un proveedor que no controla. Ninguno de los tres necesita que el modelo tenga conciencia. Solo necesita que la empresa no haya puesto reglas. Ese es el dolor real, y no aparece en ningún titular.

Riesgo 1: la fuga de datos por la puerta de siempre

El riesgo más común no es sofisticado. Es un empleado con prisa que pega información sensible en una herramienta pública para ir más rápido. Un contrato, la base de clientes, un estado de resultados, código propietario. Sale de la empresa en un copiar y pegar, y ya no vuelve.

• Datos que salen a herramientas gratuitas que pueden usar ese contenido para entrenar, o que lo guardan fuera de tu control.
• Un agente conectado al CRM o al correo sin un límite claro de qué puede leer y qué no.
• Registros y logs que almacenan los prompts completos, con datos personales de clientes adentro, en un lugar que nadie audita.

Fíjate que en ninguno de esos casos el modelo hizo algo malo. El problema fue la ausencia de una regla simple: qué información puede salir de la empresa, hacia dónde y con qué proveedor. Los proveedores serios ya ofrecen planes donde tus datos no se usan para entrenar, pero eso se configura y se exige por contrato. No se asume.

Riesgo 2: decisiones sin dueño

El segundo riesgo aparece cuando la IA empieza a decidir o a influir en decisiones de negocio: a quién le das crédito, qué lead prioriza el equipo, qué precio muestra el sistema, qué CV pasa el primer filtro. En algún momento nadie sabe explicar por qué el sistema decidió lo que decidió. Y peor: nadie responde por el resultado.

La tensión otra vez. El peligro no es que el sistema se equivoque una vez (los humanos también se equivocan). El peligro es que la decisión no tenga un dueño con nombre que pueda explicarla, defenderla o revertirla. Una decisión que nadie puede explicar tampoco se puede medir contra un KPI ni corregir cuando el número sale mal. Una automatización sin dueño no es eficiencia. Es un riesgo esperando a que alguien pregunte quién aprobó esto.

• Cada decisión que la IA toma o influye necesita un responsable humano con nombre.
• Ese responsable tiene que poder explicar el criterio y revertir el resultado.
• Las decisiones de alto impacto (dinero, personas, legal) no van en piloto automático: el sistema propone, un humano aprueba.

Riesgo 3: depender de un proveedor que no controlas

El tercer riesgo es el más silencioso, porque no duele hasta que duele fuerte. Construyes tu operación sobre la API de un proveedor. Un día suben el precio, deprecan el modelo que usabas, cambian los términos o simplemente se caen unas horas. Tu operación se detiene o tu margen se evapora, y no tienes plan B.

• No hay modelo alternativo listo: si el proveedor falla, la operación se apaga.
• Los prompts y los flujos están calibrados para un solo modelo y no son portables.
• Los datos y la lógica viven dentro de la herramienta del proveedor, sin forma de exportarlos.
• Nadie leyó qué pasa con tu información si mañana cambian los términos de servicio.

Esto no es un riesgo técnico. Es un riesgo de negocio, del mismo tipo que depender de un solo cliente o de un solo proveedor de materia prima. La respuesta no es paranoia, es arquitectura: poder cambiar de proveedor sin rehacer todo, y saber siempre dónde viven tus datos.

La seguridad no es un plugin, es arquitectura

La mayoría trata la seguridad de IA como un candado que se instala al final: un firewall, una casilla que marcas, una política que alguien firma y nadie lee. No funciona así. La seguridad se decide en el diseño del sistema, antes de encender nada.

Se decide cuando defines qué datos ve el sistema, qué puede hacer solo y en qué punto se detiene y llama a un humano. La documentación técnica de los proveedores apunta al mismo criterio: pon límites explícitos, dale al sistema el mínimo acceso que su tarea necesita y mantén a una persona en el circuito de las decisiones que importan. Eso no es una capa de seguridad encima. Es la forma en que se construye el sistema.

Qué hacer, sin caer en la paranoia

No hace falta un búnker. Hace falta un diagnóstico honesto de qué datos manejas y unos pocos controles que se sostienen en el tiempo. Los que uso al implementar:

• Clasifica los datos. Define qué información puede salir de la empresa, cuál no, y hacia qué proveedores. Sin esa regla, todo lo demás es adorno.
• Exige términos de empresa. Usa proveedores que no entrenan con tus datos y déjalo por escrito. Es una configuración, no un favor.
• Mínimo privilegio para los agentes. Un agente accede solo a lo que su tarea necesita. Ni el CRM completo ni todo el correo.
• Un dueño por decisión automatizada. Cada proceso donde la IA decide tiene un responsable con nombre que puede explicarlo y revertirlo.
• Registro y auditoría. Saber qué hizo el sistema, cuándo y con qué datos. Sin registro no hay forma de investigar cuando algo sale mal.
• Plan de proveedor. Poder cambiar de modelo o proveedor sin rehacer la operación completa.

Ajusta el control al riesgo real

No todo necesita el mismo blindaje, y sobre-asegurar mata la adopción tan rápido como sub-asegurar mata la confianza. Una lluvia de ideas interna con información pública no necesita controles pesados. La base de clientes, una decisión de crédito o el código del producto sí.

El criterio es simple: a más sensible el dato y a más alto el impacto de la decisión, más control. Ni menos, porque expones a la empresa. Ni más, porque nadie va a usar un sistema que estorba. La seguridad que funciona es la que la gente puede seguir sin sabotearla. Esa es la diferencia entre una empresa que le mete IA encima a lo que ya tenía y una empresa AI Native: la segunda diseñó el control junto con la operación, no después del susto.