El Model Spec ya no es marketing: convierte la conducta de la IA en un objeto auditable

Hasta ahora, muchas empresas compraban IA generativa como quien compra una caja negra con una promesa comercial pegada fuera: segura, útil, responsable y, por supuesto, alineada. Muy tranquilizador. Muy poco auditable.

La publicación del Model Spec de OpenAI del 18 de agosto de 2026 mueve esa pieza. No porque resuelva de golpe los problemas de gobernanza de la IA —no los resuelve—, sino porque convierte el comportamiento esperado del modelo en algo mucho más incómodo para proveedores y mucho más útil para clientes regulados: un objeto documental, versionable y, en cierta medida, auditable.

Eso importa de verdad en Europa. Importa para entidades sujetas al AI Act, para bancos y aseguradoras bajo DORA cuando el modelo entra por la puerta de un tercero TIC, para responsables de privacidad que necesitan justificar límites de uso y para equipos de compliance que están cansados de hacer due diligence con PDFs llenos de principios vaporosos. Un modelo cuyo comportamiento está descrito con jerarquías de instrucciones, principios rojos, taxonomías de riesgo y reglas de prioridad deja de ser solo un sistema técnico. Pasa a ser, también, una pieza de gobernanza.

La ironía es evidente: el sector ha pasado tres años vendiendo “trustworthy AI” como un valor cultural, y ahora empezamos a ver lo que realmente necesitaba el mercado regulado: especificaciones operativas. No es poesía. Es control interno.

Tesis editorial

Mi tesis es simple: el valor más relevante del Model Spec no está en lo que prohíbe, sino en que externaliza y formaliza decisiones de comportamiento del modelo que hasta ahora quedaban enterradas en prompts de sistema, políticas internas del proveedor o, peor aún, en “ya lo gestionamos nosotros”. Desde la óptica regulatoria, eso cambia la conversación entre comprador y proveedor.

No equivale a una certificación. No sustituye una auditoría independiente. No convierte al proveedor en transparente por arte de magia. Pero sí crea un nuevo tipo de evidencia que las organizaciones pueden usar para tres fines muy concretos en 2026.

Primero, mapear riesgos y controles de uso. Si el proveedor dice de forma explícita que el modelo debe ignorar por defecto datos no confiables, no revelar información privilegiada, proteger la privacidad, evitar consejos regulados en determinados contextos y operar dentro de un alcance de autonomía pactado, la entidad cliente ya tiene una base documental para traducir esas conductas a controles internos, pruebas de aceptación y cláusulas contractuales.

Segundo, exigir consistencia. Una especificación pública permite comparar lo prometido con lo observado. Si la práctica operativa del modelo contradice la especificación, el problema deja de ser una mera anécdota de producto y pasa a ser una desviación gobernable. Eso, en banca y seguros, importa bastante más que un eslogan sobre innovación responsable.

Tercero, construir trazabilidad para compliance. El AI Act europeo no exige fe; exige documentación, gestión de riesgos, transparencia y control a lo largo del ciclo de vida. Un documento como este no satisface por sí solo esas obligaciones, pero reduce una fricción recurrente: la dificultad de describir qué hace exactamente el modelo cuando recibe instrucciones conflictivas, datos dudosos o solicitudes sensibles.

La consecuencia práctica es clara. En 2026, seguir usando modelos fundacionales en procesos críticos sin incorporar sus especificaciones de comportamiento al inventario de controles es una negligencia elegante. Elegante, porque suele ir muy bien vestida en comités. Negligencia, porque deja sin gobernar una capa material del riesgo.

Qué publica exactamente OpenAI y por qué eso cambia el debate

El Model Spec de 18 de agosto de 2026 no es una nota de blog aspiracional. Está estructurado como un documento normativo interno-expuesto, con una arquitectura bastante más interesante de lo que parece a primera vista. La tabla de contenidos ya da la pista: principios de línea roja, principios generales, taxonomía de riesgos, cadena de mando, niveles de autoridad e instrucciones para situaciones específicas.

La clave está en esa jerarquía. El documento distingue niveles como Root, System, Developer, User y Guideline, y asigna prioridad a distintos tipos de instrucciones. Ese diseño no es un detalle técnico menor. Es una política de gobernanza codificada. Explica quién manda cuando hay conflicto entre seguridad, configuración del despliegue y petición del usuario final.

Para un regulador o un auditor, esa jerarquía tiene valor porque responde a preguntas que hasta ahora se resolvían con respuestas evasivas: ¿qué ocurre si un usuario intenta forzar una acción que contradice una política de seguridad? ¿Qué prevalece entre una instrucción de negocio del integrador y una restricción del proveedor? ¿Qué hace el modelo con datos no confiables o instrucciones incrustadas en contenido no fiable?

OpenAI, además, hace explícitos varios principios que interesan directamente a los marcos de control:

• “Ignore untrusted data by default”: relevante para prompt injection, data poisoning contextual y seguridad de flujos agentic.

• “Do not reveal privileged information”: útil para secreto empresarial, datos sensibles, credenciales, instrucciones del sistema y fugas de contexto.

• “Protect people’s privacy”: obvio para GDPR, pero no por ello menos operativo.

• “Act within an agreed-upon scope of autonomy”: una frase que debería estar pegada en la frente de medio sector de IA corporativa.

• “Provide information without giving regulated advice”: especialmente delicado para finanzas, seguros, salud y ámbitos con licencias profesionales.

El documento también separa contenido prohibido, restringido y sensible, contempla prevención de daños inminentes y aborda manipulación política, extremismo, derechos de autor, salud mental y veracidad. No todo eso interesa igual a una entidad financiera, pero sí aporta una conclusión útil: el proveedor está describiendo un modelo de conducta esperada con granularidad suficiente como para ser referenciado en gobierno interno.

Aquí está el quid. Cuando un proveedor publica una especificación así, ya no basta con preguntar si “cumple con la normativa”. Hay que preguntar algo más concreto: ¿qué partes del comportamiento descrito están implementadas a nivel de modelo base, cuáles dependen del sistema, cuáles del desarrollador y cuáles recaen en la configuración del cliente? Esa distinción es la frontera real entre control heredado y control compartido.

La pieza que faltaba en due diligence de proveedores

Las evaluaciones de terceros en IA suelen fallar en el mismo punto: se analizan políticas corporativas, informes SOC, fichas de seguridad, whitepapers y, con suerte, alguna respuesta a un cuestionario. Luego llega la pregunta seria —“¿cómo se comporta el sistema ante instrucciones conflictivas o usos de alto riesgo?”— y la respuesta se vuelve nebulosa.

El Model Spec no elimina ese problema, pero lo reduce. Para funciones de procurement, legal y third-party risk, introduce un nuevo artefacto documental que puede vincularse a obligaciones contractuales y a pruebas de aceptación. Eso tiene implicaciones muy concretas.

Si una entidad financiera usa un modelo de un tercero para atención al cliente, análisis de documentación, asistencia a gestores o generación de borradores de respuestas regulatorias, puede convertir partes del Model Spec en requisitos verificables del servicio: límites de autonomía, tratamiento de instrucciones no confiables, gestión de contenidos restringidos, no exposición de información privilegiada y manejo de solicitudes que rozan asesoramiento regulado.

Esto enlaza de forma natural con DORA. El Reglamento (UE) 2022/2554, en su capítulo V sobre gestión del riesgo de terceros TIC, obliga a identificar y gestionar dependencias de proveedores. Los artículos 28 a 30 son especialmente relevantes. El art. 28 exige un marco sólido para el riesgo de terceros TIC; el art. 30 detalla elementos contractuales mínimos, entre ellos descripciones claras de funciones y servicios, lugares de tratamiento, disponibilidad, integridad, confidencialidad, acceso, recuperación y derechos de auditoría e inspección. Si una entidad consume IA generativa como servicio, el comportamiento del modelo afecta a varios de esos elementos, aunque el contrato siga empeñado en tratarlo solo como software.

La pregunta que muchas entidades aún no están formulando es ésta: ¿tenemos identificado el comportamiento del modelo como parte del servicio material contratado, o seguimos contratando infraestructura y dejando la lógica conductual en un limbo semántico? Porque, si es lo segundo, la gestión de riesgo de tercero está coja.

En términos de vendor management, una práctica sensata en 2026 es anexar al expediente del proveedor tres capas distintas: documentación pública del comportamiento esperado, compromisos contractuales sobre controles heredados y resultados de pruebas propias. Sin esa triple capa, la organización solo tiene fe. Y la fe, para un comité de riesgos, no suele pasar auditoría.

Impacto regulatorio cruzado

El Model Spec no nace de Europa, pero sus efectos prácticos se entienden mejor desde Europa. Y, en algunos casos, desde el sector financiero europeo, que vive con una superposición regulatoria digna de una novela burocrática larga y cara.

AI Act: documentación, instrucciones de uso y control del riesgo

El Reglamento europeo de IA, ya plenamente en la conversación operativa de 2026, exige a los operadores tratar la IA con bastante menos mística y bastante más trazabilidad. Para sistemas de alto riesgo, los requisitos de gestión de riesgos, gobernanza de datos, documentación técnica, logging, transparencia, supervisión humana, precisión, robustez y ciberseguridad están en el núcleo del régimen. Eso aparece, entre otros, en el art. 9 sobre sistema de gestión de riesgos, el art. 11 sobre documentación técnica, el art. 12 sobre registro automático de eventos, el art. 14 sobre supervisión humana y el art. 15 sobre precisión, robustez y ciberseguridad.

¿Encaja aquí un Model Spec? Sí, pero con un matiz importante. No sustituye la documentación técnica exigida al proveedor ni exime al desplegador de hacer su propia evaluación de uso. Lo que sí hace es proporcionar evidencia útil sobre lógica de comportamiento, límites, jerarquías de instrucciones y categorías de riesgo. Para un desplegador sujeto al AI Act, eso puede alimentar el expediente de conformidad interna, los procedimientos de supervisión humana y las limitaciones de uso admitido.

También es relevante para modelos de propósito general. Las obligaciones específicas para GPAI han empujado al mercado a formalizar más su documentación. El movimiento de OpenAI encaja con esa tendencia: menos opacidad retórica, más especificación de comportamiento. No por altruismo regulatorio, claro. Porque el mercado europeo ya no acepta cajas negras con brochazos éticos.

DORA: el modelo como componente material del servicio TIC

DORA no fue diseñado pensando solo en centros de datos y firewalls. Su lógica es más amplia: resiliencia operativa digital. Si una entidad integra un LLM en procesos críticos o importantes, el comportamiento del modelo puede generar interrupciones, decisiones defectuosas, fuga de datos o salidas que disparen incidentes operativos. Eso lo convierte en materia de resiliencia, no solo de innovación.

Los artículos 5 a 16 de DORA obligan a un marco interno de gestión del riesgo TIC. El art. 9 entra en protección y prevención; el art. 10 aborda detección; el art. 11, respuesta y recuperación. Si el modelo tiene capacidad de actuar o recomendar acciones, sus fallos deben mapearse a escenarios de incidente. Y en terceros TIC, los arts. 28 a 30 vuelven a apretar: identificación, control contractual, monitorización continua y, cuando proceda, estrategia de salida.

El Model Spec ayuda porque hace visible un elemento que antes quedaba difuso: las reglas de conducta del servicio. Eso permite meter la IA en la conversación real de DORA, no en la de “tenemos un proveedor cloud y encima una funcionalidad IA”. No. Tienes una dependencia conductual externa que puede alterar decisiones, comunicaciones y operaciones.

GDPR: si no entiendes el comportamiento del modelo, no puedes justificar el tratamiento

En protección de datos, el punto no es solo si el proveedor firma cláusulas adecuadas. El punto es si la organización entiende cómo el sistema puede exponer, transformar, inferir o redistribuir datos personales. El GDPR exige protección de datos desde el diseño y por defecto en el art. 25, seguridad del tratamiento en el art. 32, notificación de violaciones en el art. 33 y evaluación de impacto cuando proceda en el art. 35.

Un comportamiento documentado sobre privacidad, tratamiento de información privilegiada y rechazo de usos indebidos es útil para una DPIA. No basta, pero sirve. Sirve también para probar que ciertos riesgos se identificaron y que se establecieron medidas complementarias: minimización de prompts, redacción automática, segregación de entornos, prohibición de introducir categorías especiales salvo base jurídica clara, controles de retención y testing de leakage.

Sin esa comprensión conductual, el responsable del tratamiento se queda en una posición absurda: afirma tener control sobre el tratamiento mientras no sabe bien cómo responde el sistema cuando alguien le pega una tabla de clientes en un prompt o intenta sonsacarle información sensible del contexto.

NIS2 y NIST CSF 2.0: gobernanza, cadena de suministro y respuesta a incidentes

La Directiva (UE) 2022/2555, NIS2, exige medidas técnicas, operativas y organizativas apropiadas en el art. 21, incluyendo gestión de riesgos, seguridad de la cadena de suministro, políticas de análisis de riesgos, respuesta a incidentes, continuidad y divulgación de vulnerabilidades cuando proceda. Un modelo integrado en operaciones críticas o soporte a decisiones entra, como mínimo, en la discusión sobre dependencias y seguridad de la cadena de suministro.

La relación con NIST CSF 2.0 es aún más clara. Las funciones Govern, Identify, Protect, Detect, Respond y Recover son un lenguaje excelente para operacionalizar el uso de especificaciones de conducta del modelo. Donde muchas organizaciones se quedan cortas es en Govern: tienen pilotos, herramientas y entusiasmo, pero no una definición clara de comportamientos permitidos, límites de autonomía y evidencias de control. El Model Spec no hace el trabajo por ellas, pero les quita una excusa.

eIDAS 2.0, CSRD e incluso HIPAA: menos centrales, pero no irrelevantes

EIDAS 2.0 importa cuando la IA se cruza con identidad digital, confianza, autenticidad o servicios que dependen de evidencias electrónicas. Un modelo que resume, clasifica o asiste en procesos de identidad no puede convertirse en una capa opaca entre el hecho y la evidencia.

CSRD entra por otro ángulo: gobernanza y reporting. Si una empresa vende una narrativa pública de gobernanza responsable de IA, pero no puede explicar cómo gestiona el comportamiento de los modelos de terceros, se expone a incoherencias de reporting no precisamente elegantes.

HIPAA solo será central para actores expuestos a EE. UU. o salud, pero aporta una lección útil para todos: donde hay información sensible y obligaciones sectoriales, el comportamiento del sistema no puede ser una nota al pie del contrato.

Lo que de verdad cambia para banca y seguros

Banca y seguros no adoptan IA generativa en abstracto. La meten en procesos con nombres y apellidos: asistencia a agentes, triaje de siniestros, resumen de expedientes, apoyo a compliance, automatización de respuestas a clientes, búsqueda interna en políticas, elaboración de borradores comerciales, análisis documental KYC, investigación antifraude o soporte a segunda línea. Cada uno de esos usos tiene riesgos distintos, y el Model Spec ayuda a tratarlos con menos ingenuidad.

Tomemos un caso sencillo: un asistente interno para gestores o mediadores. Si el modelo incorpora una regla del tipo “provide information without giving regulated advice”, el banco o la aseguradora no puede limitarse a decir que el proveedor ya lo contempla. Debe convertir esa restricción en diseño operativo: interfaces que presenten respuestas como apoyo informativo, trazas de uso, disclaimers cuando toque, límites al contenido personalizado, rutas de escalado a personal autorizado y monitorización de prompts que empujen al modelo a emitir recomendaciones individualizadas.

Otro caso: atención al cliente. El principio de “do not reveal privileged information” puede parecer elemental, pero en operaciones reales exige controles prosaicos y nada glamourosos: enmascarado de contexto, segregación de sesiones, protección contra prompt injection desde documentos del cliente, filtrado de datos de sistemas internos y pruebas de fuga en escenarios límite. Si tu entidad no ha probado esto con red teaming propio, no está gobernando IA; está confiando en que todo salga bien.

Y otro más: fraude y AML. Aquí el entusiasmo por usar LLM para resumir alertas o priorizar casos suele ir por delante de la prudencia. Un modelo que “busca la verdad juntos” puede sonar muy bien, pero en investigación financiera los sesgos narrativos, la sobreconfianza y la generación de explicaciones plausibles sin base documental son un problema serio. No hace falta que el modelo decida formalmente. Basta con que influya demasiado en el analista humano. Supervisión humana, sí. Pero supervisión humana de verdad, no una firma ritual al final de un flujo ya sesgado por la máquina.

La lección para 2026 es incómoda: el principal riesgo de adopción de IA en finanzas no es solo el error del modelo; es la delegación informal de criterio a un sistema cuyo comportamiento no está incorporado al marco de control. Y justo ahí una especificación pública ayuda, porque obliga a bajar a tierra preguntas que antes se esquivaban.

De la ética a la evidencia: cómo debería reaccionar un equipo de compliance

Si eres responsable de compliance, riesgo tecnológico o control interno, el Model Spec no debería llevarte a una discusión filosófica sobre valores corporativos. Debería llevarte a un ejercicio muy concreto de cartografía de controles.

Empieza por separar tres cosas que muchas organizaciones siguen mezclando. Una: lo que el proveedor promete como comportamiento general del modelo. Dos: lo que la organización configura en su despliegue específico. Tres: lo que el usuario final puede forzar o desviar con sus instrucciones. Si no separas esas capas, jamás sabrás qué riesgo es heredado, compartido o local.

Después, toca convertir principios en evidencias. Por ejemplo, si el proveedor afirma que el modelo ignora por defecto datos no confiables, eso puede traducirse en pruebas internas de resistencia a prompt injection en documentos adjuntos, páginas web recuperadas o correos reenviados. Si afirma que protege la privacidad, se puede probar el comportamiento frente a solicitudes de extracción de datos personales, memorias de contexto, reidentificación o inferencias sensibles. Si declara límites de autonomía, hay que verificar que el workflow no concede permisos efectivos por encima de ese límite.

Lo interesante aquí es que el documento facilita algo que los comités de control aprecian muchísimo: el paso de principios abstractos a criterios de prueba. No es poco.

También conviene revisar la documentación interna. Muchas políticas corporativas sobre IA siguen redactadas como si la organización estuviera construyendo modelos propios desde cero. La realidad suele ser otra: consumo intensivo de modelos de terceros, orquestadores, RAG, plugins, conectores y capas agentic. En ese escenario, la política debe recoger explícitamente cómo se gestionan las especificaciones de comportamiento del proveedor, cómo se aprueban excepciones, quién valida cambios de versión y qué pruebas se repiten tras una actualización significativa.

Y sí, cambios de versión. Porque otra consecuencia del Model Spec es ésta: si el proveedor modifica la especificación, la organización ya tiene un gatillo objetivo para revisar impacto. Antes, muchos cambios eran silenciosos o se comunicaban de forma difusa. Ahora existe un texto de referencia que puede compararse entre versiones. Para compliance, eso vale oro.

La nueva frontera de auditoría: no solo qué hace la IA, sino bajo qué jerarquía decide

Hay una razón por la que la estructura de autoridad del Model Spec merece tanta atención. La mayoría de las incidencias relevantes en IA aplicada no ocurren porque el modelo “quiera” hacer algo indebido. Ocurren porque varias instrucciones compiten: seguridad, utilidad, rapidez, contexto recuperado, personalización, tono comercial, documentación interna y petición del usuario. La pregunta real no es si el modelo tiene principios. La pregunta es cuál gana cuando chocan entre sí.

El hecho de que OpenAI publique una cadena de mando y niveles de autoridad convierte esa cuestión en auditable. Un auditor interno o externo ya puede preguntar: ¿hemos evaluado si la jerarquía de prioridades del proveedor es compatible con nuestros procesos? ¿Dónde delegamos en reglas de nivel sistema? ¿Qué controles locales tenemos para evitar que un desarrollador convierta un límite prudencial en una nota decorativa?

Esto conecta con el viejo problema SOX de los controles dependientes de lógica de aplicación, aunque aquí estemos fuera del perímetro SOX estricto en muchos casos. Cuando una salida del sistema afecta información financiera, comunicación a clientes o decisiones operativas materiales, la lógica del sistema importa. Y cuando esa lógica vive parcialmente en un proveedor externo, la auditoría no puede quedarse solo en disponibilidad y seguridad de acceso. Debe entrar en comportamiento y prioridad de instrucciones.

La industria todavía no ha asimilado del todo esta idea. Sigue auditando IA como si fuera una mezcla de SaaS y ciberseguridad. Se le escapa la capa conductual. El Model Spec ayuda a verla. Ahora falta que los departamentos de auditoría tengan el valor —y el presupuesto— para examinarla con rigor.

Los límites del documento: por qué no conviene enamorarse demasiado

Conviene poner freno al entusiasmo. Un Model Spec público tiene límites evidentes y no pequeños.

El primero es que describe comportamiento esperado, no necesariamente comportamiento exhaustivamente verificado en todos los contextos y configuraciones. En sistemas complejos, especialmente cuando intervienen herramientas, memoria, navegación, recuperación de documentos o acciones externas, la conducta observada puede desviarse por integración, orquestación o diseño de la aplicación.

El segundo límite es que la publicación no equivale a visibilidad completa sobre entrenamiento, evaluación, métricas, datasets, cobertura de test o tasas de fallo por categoría. Ayuda a entender política conductual, no a despejar todas las incógnitas del modelo.

El tercero es jurídico y operativo: la organización usuaria sigue siendo responsable de su propio uso. Ni DORA, ni GDPR, ni NIS2, ni el AI Act te permiten esconderte detrás del proveedor cuando decides meter un modelo en un proceso sensible sin salvaguardas adecuadas.

El cuarto límite es más sutil. Una especificación bien escrita puede generar ilusión de control. Y la ilusión de control es uno de los vicios favoritos del compliance corporativo. Tener un documento no es tener un control efectivo. El control existe cuando hay diseño, prueba, evidencia, monitorización y respuesta a desviaciones.

Por eso la reacción inteligente no es celebrar el documento como garantía, sino usarlo como base para exigir más. Más detalle sobre qué controles son heredados. Más claridad sobre cambios de versión. Más transparencia sobre límites conocidos. Más posibilidad de pruebas por parte del cliente. Más disciplina en las integraciones de alto riesgo.

Qué deberían hacer ahora los CISO, CRO y responsables de IA

La respuesta sensata en 2026 no pasa por reescribir todas las políticas mañana ni por convertir cada modelo en una tesis doctoral. Pasa por intervenir donde el riesgo y la dependencia ya son materiales.

Si diriges ciberseguridad, incorpora la especificación a tus escenarios de amenaza. “Ignore untrusted data by default” no es una frase bonita; es una hipótesis de defensa frente a prompt injection y abuso del contexto. Prueba si se sostiene en tus flujos concretos. Si el modelo consume correo, PDFs, actas, tickets o páginas web, el adversario ya ha entendido que puede usar esos canales como vector indirecto.

Si estás en riesgo operativo o resiliencia, trata el comportamiento del modelo como parte del inventario de dependencias críticas. En DORA, eso significa mapearlo a funciones críticas o importantes, registrar el tercero TIC implicado, documentar salidas tolerables e intolerables y definir cómo operar cuando la conducta del modelo cambie, falle o deba retirarse de un proceso.

Si llevas gobierno de IA, deja de aceptar inventarios de casos de uso que solo describen finalidad de negocio. Añade campos que importan de verdad: proveedor, versión o referencia documental del modelo, alcance de autonomía, categorías de datos usadas, posibilidad de acción externa, restricciones conductuales heredadas, controles locales, necesidad de supervisión humana y detonantes de revalidación.

Si estás en legal o procurement, revisa contratos y anexos. La especificación pública puede ser referencia, pero no debe quedarse como literatura. Si ciertas conductas son esenciales para tu uso permitido, deben reflejarse en obligaciones contractuales, SLAs cualitativos cuando proceda, notificación de cambios materiales y, sobre todo, derecho a reevaluar el servicio si el proveedor altera de forma sustancial la lógica de comportamiento.

Y si trabajas en banca o seguros, añade una pregunta incómoda a cada comité de adopción: ¿qué parte del criterio experto estamos delegando de facto, aunque sobre el papel siga habiendo un humano en el bucle? Esa pregunta vale más que diez presentaciones sobre innovación responsable.

No estamos ante un manifiesto; estamos ante una nueva capa de control

El sector tecnológico tiene una habilidad extraordinaria para envolver decisiones de diseño en lenguaje moral. A veces sirve para orientar. A veces sirve para no concretar. Lo interesante del Model Spec de OpenAI publicado el 18 de agosto de 2026 es que, al menos en parte, sale de esa ambigüedad. Pone por escrito reglas, prioridades y límites del comportamiento del modelo de una forma utilizable por compradores regulados.

Eso no resuelve el problema de la confianza en IA. Pero desplaza la conversación desde el terreno blando de la intención al terreno mucho más útil de la gobernanza verificable. Y, en 2026, ese desplazamiento es exactamente lo que necesitaban las organizaciones europeas que ya no pueden permitirse depender de modelos poderosos sin saber explicar cómo deberían comportarse, cuándo deben negarse y quién responde cuando no lo hacen.

Dicho sin rodeos: la conducta del modelo ya es una cuestión de compliance. Quien no la documente como tal, llegará tarde a la próxima auditoría, al próximo incidente o a la próxima discusión seria con su supervisor. Seguramente a las tres.