El compliance de tu agente ya es infraestructura

La distancia entre un prompt y una respuesta se mide en cobre, no solo en tokens. Antes de que una respuesta llegue a la pantalla, viaja a través de redes físicas, centros de datos y sistemas de refrigeración que dependen de cadenas de suministro de minerales en las que la mayoría de los desarrolladores nunca piensa [1]. Esa realidad material está convergiendo ahora con una legal: Nueva York se prepara para hacer cumplir su ley de seguridad de IA, que exige a los grandes desarrolladores registrarse, divulgar sus prácticas de seguridad y reportar incidentes críticos, o enfrentarse a multas [3]. Para cualquiera que construya agentes, estos dos hilos tiran en la misma dirección. El compliance ya no es un documento que escribes después del despliegue. Es una propiedad en tiempo de ejecución del propio sistema.

La capa física es una capa de gobernanza

Cada llamada de inferencia consume electricidad, y esa electricidad tiene una fuente, un costo y una huella regulatoria. El cobre que transporta la energía a través de un centro de datos se extrae, se refina y se envía bajo condiciones que son cada vez más visibles para los reguladores y auditores de la cadena de suministro [1]. Cuando un agente toma una decisión —especialmente una de alto riesgo—, el camino completo desde la extracción del mineral hasta la salida del modelo se convierte en parte de la cadena de responsabilidad.

Esto es importante porque los constructores de agentes tienden a tratar la infraestructura como problema de otro. Eliges un proveedor cloud, llamas a una API y sigues adelante. Pero la ley de Nueva York cambia el cálculo. Si estás construyendo sobre un proveedor de modelos regulado, sus obligaciones de compliance fluyen hacia abajo. Un incidente de seguridad en tu agente —por ejemplo, una instrucción financiera alucinada que cause daño— puede necesitar ser rastreado a través de toda la pila. Si el proveedor debe reportar incidentes críticos, el comportamiento de tu agente pasa a formar parte de su superficie de reporte [3]. La capa física y la capa legal están ahora acopladas.

La regulación se está dividiendo en dos conversaciones

La Web Summit de Lisboa sacó a la superficie una tensión que se traslada directamente al diseño de agentes: un bando aboga por preservar la libertad de expresión, el otro por un castigo urgente del abuso algorítmico [2]. Esto no es un único debate. Son dos conversaciones regulatorias separadas que ocurren simultáneamente, y cada una impone requisitos diferentes a los sistemas que construyes.

La regulación orientada al contenido pregunta: ¿qué dijo el agente y fue dañino? La regulación orientada a la seguridad pregunta: ¿qué hizo el agente y era previsible? La ley de Nueva York se inclina hacia la segunda pregunta. Exige la divulgación de prácticas de seguridad y el reporte de incidentes, lo que significa que necesitas mecanismos para detectar, registrar y explicar las acciones del agente antes de que se conviertan en incidentes [3]. La conversación europea, mientras tanto, sigue dando vueltas a la primera pregunta —responsabilidad de plataforma, discurso y moderación— lo cual importa si tu agente publica contenido o interactúa con usuarios en canales públicos [2].

Para un framework de agentes, esta división es práctica. Necesitas primitivas de gobernanza que manejen ambas cosas: filtros de contenido para el lado del discurso, y registros de auditoría con umbrales de severidad para el lado de la seguridad. Ninguna de las dos puede añadirse después, porque las obligaciones de reporte asumen que esas primitivas existen en tiempo de ejecución.

Lo que esto significa para el código que escribes

La conclusión práctica no es "lee la ley". Es que tu harness de evaluación del agente debe funcionar también como un artefacto de compliance. Si Nueva York exige divulgaciones de seguridad, la forma honesta de cumplir ese requisito es tener evaluaciones que se ejecuten continuamente, produzcan resultados verificables y alimenten la detección de incidentes. Un documento de seguridad estático enviado una vez al año no sobrevivirá a una revisión de incidente.

Tres cosas se vuelven innegociables. Primero, cada acción del agente que pueda desencadenar un incidente reportable necesita un clasificador de severidad que se ejecute en banda, no como un pipeline separado. Segundo, la fusión de modelos —combinar múltiples modelos para diferentes tareas— requiere metadatos de seguridad por modelo, porque un modelo abierto fine-tuneado y una API cerrada conllevan una exposición regulatoria diferente. Tercero, el costo de la inferencia es ahora una métrica de gobernanza. Si un modelo más barato reduce el consumo de energía pero aumenta el riesgo de alucinación, el trade-off no es solo técnico; es algo que un regulador o un auditor puede pedirte que justifiques.

El cobre en el cable y la ley en los libros están convergiendo en el mismo punto: el agente que envías a producción es responsable de toda su cadena de suministro, desde el mineral hasta el modelo y la salida. Construye ahora la infraestructura de registro, clasificación y evaluación, porque los requisitos de reporte ya se están aplicando [3].