Adopción de IA para líderes de TI: un plan que pone la seguridad primero sin frenar al negocio

Casi todos los consejos sobre adopción de IA los escribe gente que nunca cargó con un incidente. Te dicen "abraza la IA" o "prohíbela hasta que sea segura". Las dos están mal. Si la prohíbes, para el viernes tu equipo ya está pegando datos de clientes en un chatbot de consumo desde el teléfono. Si la abrazas sin límites, te enteras seis meses después de que un montón de contratos pasaron por un plan gratuito que entrena con tus datos. Lo que te llevas de aquí es una secuencia por etapas y aburrida que te deja adoptar IA rápido y dormir tranquilo: límites antes que herramientas, reemplazo antes que prohibiciones, mínimo privilegio antes que comodidad, logs antes que escala.

Llevo una empresa de una sola persona, Ilustrari (que opera como NexoString), construyendo sistemas multiagente y de apoyo a la decisión sobre Anthropic Claude, TypeScript, Next.js y Supabase. Vengo de liderazgo de TI, ingeniería de telemática y seguridad. Este es el plan que de verdad ejecutaría dentro de una organización, no el que gana una charla de conferencia.

01 · Empieza por los límites de datos, no por las herramientas

Cada decisión que sigue nace de una pregunta: ¿qué datos puede ver la IA y a dónde van? Respóndela primero y casi todos los debates de "política de IA" se evaporan, porque dejas de discutir herramientas en abstracto y empiezas a discutir datos concretos en herramientas concretas.

Clasifica tus datos en tres niveles, en lenguaje simple que cualquiera aplique sin un abogado al lado:

1. Verde: ya es público o no hay problema en que lo sea. Copy de marketing, docs publicadas, código abierto. Pégalo donde quieras.
2. Amarillo: interno pero no regulado. Notas de reunión, wikis, código que no es de cliente. Solo herramientas aprobadas con contrato de no-entrenamiento.
3. Rojo: regulado o contractual, datos personales, de salud, de pago, secretos, datos de clientes bajo acuerdo. Nunca en una herramienta de IA general. Si tiene que tocar un modelo, pasa por un sistema que tú controlas, con enmascaramiento de datos por delante.

Aquí ganas velocidad, no papeleo. Una etiqueta que un empleado aplica en dos segundos le gana a un documento de cuarenta páginas que nadie lee. El límite es el producto: todo lo que viene después (el puntaje del proveedor, los permisos del agente, la retención de logs) hereda el nivel.

02 · Haz una revisión de proveedor que quepa en una semana

No necesitas un ciclo de compras de seis meses. Necesitas respuestas a cinco preguntas, por escrito, del proveedor:

• Entrenamiento: ¿usan nuestras entradas y salidas para entrenar modelos? Quieres un "no" contractual en los planes de pago, no un post de blog.
• Retención: ¿cuánto guardan los datos y se puede acortar o apagar?
• Subprocesadores: ¿quién más toca los datos, qué nube, qué región?
• Acceso y SSO: ¿puedes exigir SSO, SCIM y roles por usuario, o son cuentas compartidas?
• Logs y exportación: ¿puedes sacar una auditoría y exportar tus propios datos?

Anthropic, por ejemplo, declara que por defecto no entrena sus modelos con las entradas de su API de negocio ni con datos comerciales. Ese es el tipo de compromiso al que te anclas en el contrato, no de palabra. Califica cada proveedor verde/amarillo/rojo en esas cinco preguntas y sigue.

El cambio de enfoque que destraba casi cualquier revisión: la revisión de riesgo acota una herramienta, no la bloquea hasta matarla. Una herramienta que reprueba en "entrenamiento" para datos Rojos igual puede aprobarse hoy para Verde y Amarillo. No estás bendiciendo la herramienta para siempre; estás decidiendo a qué nivel se le permite acercarse. Esa distinción es la diferencia entre entregar este trimestre y volver a pelear el mismo hilo de Slack los próximos dos.

03 · El shadow-AI es una señal de demanda, no un delito

Si la gente está pegando trabajo en herramientas no aprobadas, eso no es un problema de disciplina. Es demanda no atendida, y tu lista de bloqueo pierde contra un teléfono con correo personal. De esto no sales a punta de firewall: la salida siempre está a un toque del modo avión.

El arreglo que dura es reemplazo, no prohibición. Dale a tu gente una herramienta autorizada que sea de verdad más rápida que la del shadow, con SSO para que aparezca en su inicio de sesión de siempre, y el uso no autorizado baja solo. Ahí sí puedes bloquear los endpoints de consumo con la conciencia tranquila, porque hay un mejor camino y no solo una barrera.

El patrón que siempre me funcionó es hacer que el camino seguro sea el fácil. Un gestor de secretos como Infuse, el nuestro para llaves de API, existe justo por eso: nadie copia una llave en un DM de Slack cuando obtenerla bien cuesta menos esfuerzo que hacerlo mal. La seguridad que le cuesta fricción al usuario es seguridad que la gente esquiva. La que le cuesta menos fricción se hace cumplir sola.

04 · Da mínimo privilegio a las herramientas, sobre todo a los agentes

Aquí es donde la IA rompe el modelo de seguridad de siempre. Un chatbot lee. Un agente actúa: llama herramientas, pega a APIs, escribe en bases de datos, mueve estado real. El radio de impacto es todo lo que le conectaste, y "todo lo que le conectaste" tiene la maña de crecer en silencio.

Trata a cada agente como un contratista junior con una cuenta de servicio acotada:

• Una cuenta de servicio por agente, nunca un token de admin compartido.
• Solo lectura por defecto. La escritura se concede por herramienta, por recurso, y se justifica en una frase.
• Acota también en la capa de datos. Con Supabase nos apoyamos en Row Level Security para que un token literalmente no pueda leer filas que no le tocan. La base de datos hace cumplir el límite aunque el prompt del agente se vaya de lado.

Así se ve una lista de permitidos (allowlist) por herramienta para un agente. Fíjate que deniega por defecto y que la operación destructiva simplemente no está, no está denegada con un flag, sencillamente no aparece:

agent: triage-soporte
service_account: svc-triage-soporte
permissions:
  - tool: tickets.read
    scope: "team:soporte"
  - tool: tickets.comment
    scope: "team:soporte"
  - tool: kb.search
    scope: "public"
# sin tickets.delete, sin billing.*, sin admin.*
# lo que no se lista, se deniega

En Agent Orchestra, nuestro proyecto visual de orquestación multiagente, el orquestador nunca recibe una llave con permiso total. Cada worker carga solo los permisos que su tarea necesita, y el trabajo del orquestador es enrutar, no actuar. Así, un agente con prompt injection, y los van a inyectar (es cuestión de cuándo, no de si pasa), en el peor caso abusa de una porción estrecha, no de todo tu backend.

05 · Registra todo y después léelo de verdad

Si no puedes responder "qué agente hizo qué, sobre qué registro, con qué prompt y cuándo", no tienes IA en producción: tienes un riesgo legal con interfaz de chat.

Registra prompts, llamadas a herramientas, recursos tocados y el resultado, en un almacén de solo-anexar. La razón no es paranoia, es poder depurar: cuando un agente hace algo tonto, la traza te dice si fue un mal prompt, un mal permiso o una inyección, tres arreglos completamente distintos que desde afuera se ven idénticos.

Unas reglas para que el logging no termine siendo un riesgo en sí mismo:

1. Define la retención a propósito: suficiente para investigar un incidente real, corta para respetar el nivel Rojo. Los logs de datos Rojos siguen siendo datos Rojos.
2. Enmascara antes de guardar, no después. Un secreto que cae en tu almacén de trazas es ahora un secreto en dos lugares.
3. Pon alertas solo en lo que importa, no en todo: un agente tocando datos Rojos, un pico de errores de herramienta, una cuenta de servicio usada desde un lugar nuevo. Una alerta que nadie lee es un log con pasos extra.

06 · Escalona el despliegue para que no se trabe

Seguridad primero no significa lento. Significa por etapas. Este es el orden que de verdad entrega:

1. Semanas 1 a 2: publica los niveles. Aprueba una herramienta para Verde/Amarillo. Listo. La mayoría solo necesitaba eso, y entregarlo rápido te compra la credibilidad para los pasos difíciles.
2. Semanas 3 a 6: despliega esa herramienta con SSO. Mira cómo cae el shadow-AI. Corre la revisión de cinco preguntas sobre las próximas dos herramientas pedidas.
3. Trimestre 2: introduce agentes, solo lectura, con logs, alcance estrecho, en un solo flujo. Mide antes de ampliar nada.
4. Continuo: re-revisa permisos cada trimestre. Revoca lo que no se usa. El privilegio se pudre: una cuenta que estaba bien acotada en enero ya acumuló tres permisos "temporales" para abril.

07 · Cuándo no hacer esto

Sé honesto sobre dónde la IA todavía no tiene lugar. No pongas un agente autónomo a cargo de acciones irreversibles (mover dinero, borrar en producción, comunicación externa) sin una aprobación humana por delante. No le des datos Rojos a un modelo solo porque un demo impresionó a alguien en la sala. Y si no lo puedes registrar, no lo despliegues: una capacidad que no puedes auditar es una que en realidad no controlas, solo confías en que se porte bien.

La conclusión es simple. Límites antes que herramientas, reemplazo antes que prohibiciones, mínimo privilegio antes que comodidad, logs antes que escala. Haz esas cuatro en orden y el dilema velocidad-contra-seguridad casi se disuelve: lo lento nunca fue el precio de ser cuidadoso, es el impuesto que pagas por saltarte las partes aburridas.