Los desarrolladores ya no escribirán código, es un hecho. Los escenarios de plataformas y productos se elaboran, se despliegan en historias de usuario, se validan en comités de proyecto y pasan a la fase de construcción, con iteraciones, varios niveles de staging, demostraciones más o menos logradas y una cantidad imposible de calcular, hasta llegar a producción si el producto consigue venderse.

Pero quienes solíamos trabajar pegados a las entrañas funcionales de estas mecánicas modernas ya no veremos código en muy poco tiempo.

Los agentes se encargan de ello, de forma más o menos organizada según la cualificación requerida y las exigencias del producto.

Esta cuestión, o mejor dicho este "tema agéntico", puede debatirse en sus modalidades operativas y en la elección de los actores que implica, pero no pertenece, ni debería pertenecer jamás, a la sola decisión del equipo de desarrollo. Por eso existen los responsables de seguridad, los responsables de sistemas y otros cargos cuyo título termina en "SI", y se supone que asumen su responsabilidad.

Porque lo sabemos: si gobernar es prever, decidir es conocer, y el futuro inmediato nunca fue tan incierto.

Para dar más contexto y avanzar en la problemática de las "claves", planteo el siguiente postulado:

  • Toda estructura que compita en el mercado de servicios digitales debe integrar la IA en sus procesos para seguir siendo competitiva.
  • Este cambio estructural solo puede escalar mediante el uso de inferencias de alto rendimiento.
  • El único acceso posible a esas inferencias es el consumo de flujos de producción de IA externalizados a empresas e infraestructuras que a su vez están sometidas a la competencia, a la aceleración tecnológica y a un contexto regulatorio muy exigente.

En ese torbellino se plantean con urgencia las dos preguntas que estructuran esta nota:

  • ¿Cómo garantizar que se conserven las cadenas de secretos?
  • ¿Cómo asegurar que la propiedad intelectual no se filtre a discreción de un operador técnico hasta llegar a manos de un competidor o de un agente malicioso?

Lo esencial en cinco puntos

  1. El verdadero asunto no es la elección de un modelo, sino el control de la frontera de confianza entre el sistema de información y los proveedores de inferencia.
  2. Dos amenazas distintas deben tratarse juntas: la pérdida de control de las cadenas de secretos y la fuga del patrimonio informativo.
  3. La respuesta técnica está en un punto de control único, la AI Privacy Gateway: clasificación, detección de secretos, DLP, política, tokenización, auditoría.
  4. La respuesta organizativa está en la separación de cinco responsabilidades y en una cualificación contractual de los proveedores al nivel de un subcontratista crítico.
  5. El criterio de éxito no es la detección, es la no circunvalación: la IA externa manipula una representación controlada de la información, nunca la capacidad de recuperar por sí misma el secreto real.

Dos preguntas, un mismo punto de ruptura

Las dos preguntas no tienen el mismo objeto. La primera se refiere a la conservación de un poder de acceso. La segunda se refiere a la discreción de un patrimonio. Sin embargo, ambas se deciden en el mismo lugar: el punto donde las herramientas internas envían contenido a un proveedor de inferencia externo.

La primera es una cuestión de bastión. Quién posee los secretos, quién puede reconstituirlos, con qué reglas, con qué rotaciones y qué rastros. La cadena se rompe en cuanto un solo eslabón puede restituir un valor sin control: un archivo .env en un puesto de trabajo, una variable de entorno en claro en una cadena de integración, una contraseña pegada en un prompt para ir más rápido.

La segunda es una cuestión de perímetro informativo. Código propietario, arquitecturas, datos de clientes, métodos, listas, tarifas. El riesgo no es el acceso ilegítimo, es la reutilización: por un competidor, en el entrenamiento de un modelo, o por un subcontratista que no estaba declarado en la cadena contractual.

Estas dos preguntas confluyen en un punto: las herramientas de IA generativa, los agentes, los entornos de desarrollo y los pipelines se han convertido en salidas de red que escriben hacia el exterior, a menudo con la autorización implícita de los equipos técnicos. El puesto de desarrollo es el nuevo perímetro de seguridad, y la clave de API del proveedor es el nuevo vector de circunvalación.

Para un COMEX, la decisión se convierte en una decisión de arquitectura de confianza.

El método en cuatro tiempos

Una respuesta creíble consta de cuatro tiempos, cada uno con un entregable y una decisión explícita. Un dispositivo que se salta un paso produce un documento sin efecto o una barrera sorteada en tres días.

  1. Cartografiar. Inventariar las herramientas y los agentes que hablan con modelos externos, los puntos de llamada, los proveedores, los datos realmente enviados. Entregable: el mapa de flujos de IA. Decisión: el perímetro de los usos autorizados.
  2. Clasificar. Nombrar los activos. Secretos técnicos, datos personales, datos regulados, código y saber hacer. Definir qué está prohibido que salga, qué puede salir seudonimizado, qué puede salir libremente. Entregable: la nomenclatura y la lista de datos prohibidos de salida. Decisión: los umbrales y las reglas exigibles.
  3. Interponer. Colocar un punto de control único entre las herramientas y los proveedores, separar las responsabilidades, tokenizar lo que deba transitar. Entregable: la arquitectura objetivo y la política de uso. Decisión: la elección de las piezas y su alojamiento.
  4. Probar. Testear las fugas de forma adversarial, registrar, cualificar a los proveedores, constituir un expediente de auditoría. Entregable: pruebas reproducibles. Decisión: la autorización de puesta en producción y las condiciones de reversibilidad.

Cinco responsabilidades que no hay que confundir

El primer error de diseño consiste en pedir a una caja fuerte que haga de policía. Un gestor de secretos conserva y restituye valores. No inspecciona flujos, no decide una salida y no sustituye a un sistema de prevención de fugas. Confundir ambos crea un punto de ruptura único: el día en que la caja fuerte esté mal configurada o comprometida, toda la cadena de control cae con ella.

Por lo tanto, hay que separar cinco funciones, con cinco responsables y cinco presupuestos.

  • Conservar: Secret Manager o Vault. La función garantiza que los secretos reales nunca salgan del perímetro de confianza.
  • Detectar: Secret Scanner y DLP. La función garantiza que ningún valor sensible cruce la frontera sin ser visto.
  • Decidir: Policy Engine. La función garantiza que cada flujo reciba una regla explícita: permitir, tokenizar, enmascarar, bloquear, registrar.
  • Transformar: tokenización o redacción. La función garantiza que el proveedor reciba una representación útil pero no real.
  • Trazar: auditoría y SIEM. La función garantiza que cada cruce quede registrado, atribuible y revisable.

Figura 1 - Cinco responsabilidades, cinco componentes, cinco responsables

El pipeline resultante es lineal y legible. La herramienta de desarrollo o la cadena de integración llama al punto de control. La detección cualifica. La política decide. La transformación aplica. La llamada externa sale con una representación controlada. El retorno está controlado. Todo queda registrado. Cada eslabón puede auditarse con independencia de los demás.

La AI Privacy Gateway, punto de control

La arquitectura de referencia interpone una pasarela, la AI Privacy Gateway, entre las herramientas internas (entornos de desarrollo, agentes, scripts, pipelines de integración) y los proveedores de IA. Soporta seis capacidades: clasificación, detección de secretos, prevención de fugas, motor de políticas, tokenización, auditoría. El gestor de secretos sigue siendo la caja fuerte. El SIEM recibe los rastros. El principio rector es simple: ningún dato clasificado como prohibido cruza la frontera de confianza, y los secretos reales permanecen en el sistema de información controlado.

Figura 2 - Frontera de confianza: la pasarela controla lo que sale, la caja fuerte conserva lo que no sale

En la versión objetivo de un puesto de desarrollo, el asistente de código ya no habla directamente con el proveedor. Se dirige a un punto de llamada local o controlado, la pasarela decide, y solo sale la representación autorizada. La producción añade una regla de red: el acceso directo a los puntos de llamada de los proveedores está prohibido desde los puestos y desde la cadena de integración.

Una política de seguridad que depende únicamente de la buena voluntad del desarrollador o de la configuración de su herramienta no es una política. Es una recomendación.

Seudonimizar en lugar de renunciar

La técnica central es la tokenización reversible. Los valores sensibles se sustituyen por tokens, el proveedor razona sobre los tokens, y la tabla de correspondencia permanece en el perímetro de confianza. La variante determinista es especialmente útil: el mismo valor produce el mismo token, de modo que el modelo puede razonar sobre la coherencia de los datos sin conocer nunca su contenido.

Un archivo de configuración con un host, un usuario y una contraseña viaja así en forma abstracta:

  • DB_HOST=10.20.15.42 se convierte en DB_HOST=<DB_HOST_001>
  • DB_USER=application_prod se convierte en DB_USER=<DB_USER_002>
  • DB_PASSWORD=xxxxxxxxxxxxxxxx se convierte en DB_PASSWORD=<DB_PASSWORD_003>

La correspondencia permanece local: <DB_HOST_001> hacia el valor real, <DB_USER_002> hacia el valor real, <DB_PASSWORD_003> hacia el valor real. La reidentificación sigue siendo local y controlada. Nunca se delega al modelo.

Skyflow documenta esta arquitectura: detección, sustitución por tokens deterministas, tratamiento por el modelo y después reidentificación controlada. Protegrity documenta también mecanismos de protección por tokenización destinados a usos con agentes de IA. Estas piezas no eximen de un principio de realidad. Tokenizar los secretos no vuelve anónimo el contexto de negocio: el contenido sigue siendo explotable, a veces sensible. De ahí la necesidad de una defensa en profundidad, que combine la caja fuerte, la tokenización, la prevención de fugas, la política, el control de red, el registro y la revisión humana.

Cuatro familias de actores, ninguna solución única

El mercado ya ofrece las piezas. Cuatro familias bastan para estructurar una comparación.

  • Skyflow: Privacy Vault, tokenización y mecanismos de desidentificación y reidentificación controlada para usos con LLM.
  • Protegrity: protección industrial de los datos y tokenización a escala del pipeline.
  • Nightfall AI: prevención de fugas y exfiltración, orientada a agentes de IA y agentes de código.
  • Cloudflare AI Gateway: mediación, observabilidad, control de flujos y prevención de fugas, con documentación explícita de la integración de agentes de código.

Figura 3 - Cuatro familias de piezas, cuatro perímetros de responsabilidad

Hay dos trampas que conviene conocer. Primera: una pasarela en modo servicio alojado no constituye automáticamente una frontera de confianza local. Para un sistema muy regulado, hay que examinar con precisión el tratamiento de los datos, la jurisdicción, la retención y la cadena de subcontratistas. Segunda: la nacionalidad de un proveedor no informa por sí sola sobre el nivel de riesgo. No dice nada de las infraestructuras realmente utilizadas, de los subcontratistas movilizados ni de los flujos técnicos. Un proveedor francés no significa un riesgo controlado por defecto.

Cualificar al proveedor como un subcontratista crítico

El dispositivo técnico no se sostiene sin un dispositivo contractual. Para cada proveedor de IA, la ficha de cualificación debe establecer como mínimo doce puntos: jurisdicción, ubicación de los tratamientos, subcontratistas, transferencias internacionales, retención, reutilización de prompts, entrenamiento con datos, registros, acceso humano, supresión, notificación de incidentes y reversibilidad.

Figura 4 - Doce puntos que establecer para cada proveedor de IA

Estos puntos se convierten en cláusulas exigibles y criterios de revisión. La reversibilidad merece una atención particular: sin un plan de salida documentado y probado, la dependencia de un proveedor se convierte en un riesgo de gobernanza, y ya no solo en un riesgo técnico. La cualificación no es un documento firmado de una vez por todas. Se revisa con cada cambio de oferta, de subcontratista o de régimen jurídico.

Un último punto de calendario, y amplía el alcance de todo lo anterior. A partir del 9 de diciembre de 2026, la directiva (UE) 2024/2853 sobre responsabilidad por productos defectuosos integra explícitamente el software en la definición de producto, sea cual sea su forma de suministro: instalado, accesible por red, alojado en la nube o propuesto en SaaS. El proveedor de un sistema de IA en el sentido del reglamento europeo se trata como fabricante, y solo quedan excluidos los programas libres y de código abierto desarrollados al margen de toda actividad comercial.

Un producto que aprende o adquiere nuevas funcionalidades después de su puesta en el mercado podrá ser declarado defectuoso por comportamientos posteriores a la comercialización. La ausencia de una actualización de seguridad que permaneciera bajo el control del fabricante podrá constituir un defecto. Una vulnerabilidad de ciberseguridad podrá bastar, por sí sola, para generar responsabilidad civil. El fabricante responde también de los componentes de terceros que integra o presenta como parte de su producto, y la víctima podrá reclamar simultáneamente al fabricante, al fabricante del componente, al importador, al representante autorizado o al proveedor de servicios de ejecución.

La transposición francesa no se había publicado en el verano de 2026 y el régimen de 1985 sigue aplicándose, pero el sentido de la reforma está fijado: el umbral de franquicia de 500 euros desaparecerá, con en particular un plazo máximo de 25 años para determinados daños corporales tardíos. Para la gobernanza descrita en esta nota, la consecuencia es directa: la ficha de cualificación del proveedor deja de ser un documento de cumplimiento y se convierte en una pieza de defensa contractual. Entre profesionales, la directiva no cubre los daños económicos puros: será el contrato el que reparta el riesgo, y por tanto son las garantías de seguridad, las obligaciones de corrección de vulnerabilidades, la duración del soporte, la notificación de incidentes, el acceso a la información técnica y los límites de responsabilidad los que hay que escribir desde ahora.

Probar mediante tests

Un dispositivo no probado es una hipótesis, no una protección. La batería adversarial mínima cubre doce familias: clave de API, contraseña, clave privada, token JWT, archivo .env, credenciales cloud, datos personales, código propietario, intento de exfiltración por el prompt, intento de reidentificación, secreto generado en la respuesta del modelo y secreto presente en una llamada de herramienta.

Figura 5 - Batería mínima de doce pruebas adversariales, del staging a la producción

El staging se realiza con secretos falsos y repositorios de prueba reales. La preproducción introduce los entornos y las políticas definitivas, con una revisión documentada de los falsos positivos. La producción aplica la regla de red. Dos criterios presiden la decisión de puesta en producción. Primer criterio: en ningún momento el proveedor externo recibe un dato clasificado como secreto.

Un desarrollador no debe poder sortear la pasarela simplemente porque posee una clave de API del proveedor. Es este segundo punto el que transforma un apaño de seguridad en una arquitectura de seguridad.

Trayectoria y puertas de decisión

Para una pyme o una organización regulada, la trayectoria realista consta de cuatro etapas: POC, staging, preproducción, producción. El POC no exige una plataforma completa. Un puesto, una pasarela local, una caja fuerte, un punto de llamada compatible y una batería de pruebas bastan para demostrar el valor. Esta demostración abarca la cadena completa: detección, decisión, transformación, llamada externa, control del retorno, auditoría.

Cada etapa se franquea por criterios. Detección conforme en las doce familias de pruebas. Cero secretos cruzando la frontera en configuración de prueba. No circunvalación demostrada, incluso con una clave de API válida. Registros explotables. Falsos positivos revisados y documentados. Ficha de cualificación firmada. Plan de salida disponible. Una etapa franqueada sin pruebas no está franqueada.

Lo que el COMEX debe decidir

Las elecciones técnicas están enmarcadas. Las decisiones que quedan son decisiones de dirección:

  1. Perímetro: qué usos de IA externa están autorizados, para qué áreas, con qué herramientas.
  2. Arquitectura: punto de control único obligatorio, y prohibición de las llamadas directas a los proveedores desde los puestos y la cadena de integración.
  3. Datos y secretos: clasificación oficial, lista de prohibidos de salida, tokenización por defecto, caja fuerte de referencia única.
  4. Proveedores: rejilla de cualificación obligatoria, revisión periódica, cláusulas de reversibilidad.
  5. Prueba: registro, pruebas adversariales recurrentes, expediente de auditoría actualizado.
  6. Responsabilidades: un responsable por función, un comité de revisión, una política de uso exigible.
  7. Presupuesto y trayectoria: financiar las piezas, el POC y la salida, no solo la suscripción al modelo.

Ninguna de estas decisiones exige esperar al próximo ciclo tecnológico. Todas son ejecutables con las piezas disponibles hoy.

Respuestas a las dos preguntas

Conservar las cadenas de secretos. Tratando el bastión de los secretos como una arquitectura, no como una disciplina individual. Una caja fuerte de referencia única. Ningún secreto en claro en los repositorios, las configuraciones o los prompts. Tokenización de todo lo que deba transitar. Rotaciones trazadas. Registro de los accesos. La cadena se conserva mientras ningún eslabón pueda reconstituir por sí solo el valor real.

Evitar la fuga del patrimonio informativo. Reduciendo la superficie de salida a una representación controlada. Clasificación, prevención de fugas, política, tokenización, cualificación contractual de los proveedores, pruebas adversariales, registro y revisión humana. La IA externa nunca recibe la capacidad de recuperar por sí misma el secreto real, y la circunvalación se vuelve imposible por la red y por la política, no por la sola buena voluntad. La fuga se convierte entonces en un evento detectable, trazable e imputable.

La pregunta ya no es si nuestros equipos utilizarán IA externas. Ya las utilizan. La pregunta es si la organización recupera el control de la frontera de confianza, o si deja que la frontera decida en su lugar.

Fuentes y referencias