El cumplimiento regulatorio como infraestructura: reglas como código, agentes en los bordes

Hay un momento en casi todas las conversaciones que tenemos con equipos regulatorios en el que alguien abre una hoja de cálculo con cuarenta pestañas, una por mercado, y pide disculpas por ella. No debería. Esa hoja de cálculo es a menudo la codificación más completa que existe del conocimiento regulatorio de la empresa, mantenida bajo presión por un equipo pequeño que además tiene que responder cada “¿podemos enviar esto a Corea?” o “¿este ingrediente sigue pasando en China?”.

El problema no es la hoja de cálculo, ni la gente que la mantiene. El problema es que ese conocimiento no tiene infraestructura. Una fórmula puede tener que superar los Estándares IFRA, los anexos del Reglamento europeo de cosméticos 1223/2009, las restricciones de REACH, los inventarios nacionales de ingredientes cosméticos y umbrales, prohibiciones y excepciones específicos de cada mercado. Y las reglas se mueven: IFRA avanza de su Enmienda 51 hacia la 52, el Reglamento europeo de cosméticos sigue recibiendo actualizaciones, y la NMPA china ha introducido un mecanismo dinámico para mantener su Inventario de Ingredientes Cosméticos Existentes. Comprobar una fórmula contra un mercado es trabajo cuidadoso. Volver a comprobar cientos o miles de fórmulas tras un cambio es otra cosa completamente distinta.

La tentación, y dónde ayudan de verdad los modelos de lenguaje

El movimiento obvio de 2026 es entregarle el problema a un modelo de lenguaje. Hay una idea útil enterrada en ese instinto: el material regulatorio está escrito para humanos, repartido entre webs, documentos e idiomas, y los modelos de lenguaje son genuinamente útiles para navegarlo. Pueden localizar los pasajes relevantes, resumir enmiendas, comparar documentos, traducir el material original y convertir una pregunta como “¿podemos usar esto en Corea?” en la investigación necesaria para responderla.

Pero el modelo no debe convertirse en el sistema de cumplimiento. Un umbral alucinado no es un bug menor de software; es un fallo de cumplimiento, y “probablemente conforme” no tiene ningún significado operativo. La separación útil es directa: modelos donde la entrada es prosa ambigua, y código donde la respuesta es una regla.

Eso significa recopilar las fuentes regulatorias en una base de datos estructurada y versionada, conservar la fuente original detrás de cada registro, y codificar los requisitos que pueden evaluarse de forma determinista. La capa conversacional se apoya entonces sobre esa infraestructura, en lugar de sustituirla.

Reglas como código

La idea no es nueva. Los gobiernos llevan años explorando la legislación consumible por máquinas, y el mismo principio se aplica de forma natural al trabajo regulatorio en formulación. Allí donde un requisito puede expresarse de forma determinista, el sistema debe hacer exactamente eso.

Una regla codificada necesita más que un umbral. Necesita la sustancia o ingrediente al que aplica, el mercado, la categoría de producto, condiciones y excepciones, fechas de vigencia, documento fuente y versión de la base de reglas. Una comprobación de cumplimiento puede entonces convertirse en:

esta fórmula + este mercado + esta versión de la base de reglas → estas reglas activadas.

Para la regulación estructurada —inventarios químicos, listas de prohibidos, límites de concentración y otras restricciones cuantitativas— la diferencia es dramática. Un trabajo que antes significaba comprobar compuestos a mano entre hojas de cálculo, webs y documentos fuente durante días o semanas puede convertirse en una evaluación de base de datos sobre todo el portfolio en minutos. Veinte mercados ya no son veinte búsquedas independientes; para las comprobaciones codificadas, son una consulta en lote.

La misma infraestructura puede volver a ejecutarse cada vez que la regulación cambia. Cuando aterriza una enmienda, la pregunta deja de ser “¿qué hojas de cálculo tenemos que revisar?” para ser “¿qué fórmulas quedan afectadas?”

Dónde encajan los agentes

No toda pregunta regulatoria cabe limpiamente en código. Los requisitos pueden depender del uso previsto, la identidad del ingrediente, la documentación, excepciones o lenguaje que exige interpretación experta. Las sustancias naturales complejas pueden aportar constituyentes restringidos de forma indirecta, los nombres de ingredientes no siempre mapean bien entre sistemas, y las publicaciones nuevas pueden introducir ambigüedad.

Esos casos no deben forzarse a un aprobado o suspenso. Revisión necesaria es un resultado válido.

Aquí es donde los agentes son útiles. Un agente puede recuperar una enmienda nueva, identificar qué parece haber cambiado y proponer una actualización de la base de reglas con la fuente de apoyo adjunta. Un experto regulatorio la revisa y la aprueba antes de que se vuelva autoritativa. En el otro extremo, cuando una comprobación es ambigua, la misma interfaz puede sacar a la superficie los registros relevantes, recuperar la fuente subyacente y traducirla o resumirla para su revisión.

La división del trabajo es deliberada: el agente acelera la lectura y la ingesta; el experto conserva la autoridad; la base de reglas se mantiene determinista. El objetivo no es automatizar el juicio regulatorio, sino eliminar el trabajo repetitivo que lo rodea.

Lo que esto desbloquea

Cuando el conocimiento regulatorio tiene infraestructura detrás, el cumplimiento deja de ser un problema de búsqueda repetido desde cero. Un equipo puede preguntar qué fórmulas contienen un ingrediente recién afectado por una enmienda, qué productos pasan en un mercado pero fallan en otro, qué ingrediente o dosis impide que una fórmula se vuelva global, o qué productos necesitan revisión inmediata tras un cambio regulatorio. El triaje del portfolio se convierte en una consulta, no en un proyecto.

La misma capa adelanta el cumplimiento en el desarrollo. Los formuladores pueden ver las restricciones regulatorias mientras diseñan, en lugar de descubrirlas al final. Con el tiempo, los sistemas de optimización y formulación generativa pueden usar la misma base de reglas como capa de restricciones, buscando dentro del espacio regulatorio permitido en lugar de generar candidatos libremente y filtrar las violaciones después.

Igual de importante: cada respuesta sigue siendo trazable. Un resultado útil no es simplemente “UE: falla.” Es: esta fórmula, evaluada contra esta versión de la base de reglas, activó esta regla, derivada de esta fuente, vigente desde esta fecha. Esa procedencia hace el resultado reproducible en software, defendible en auditorías y accionable para los equipos de producto.

El punto de llegada aspiracional es una capa regulatoria que se comporte como el type-checking en programación: siempre disponible mientras trabajas, casi invisible cuando todo pasa, y precisa sobre qué falló cuando no. Los equipos regulatorios no deberían pasar su tiempo demostrando una y otra vez hechos que un sistema puede comprobar en segundos. Deberían dedicarlo a los casos donde la respuesta exige de verdad un experto regulatorio.

Ese es el sentido del cumplimiento regulatorio como infraestructura: no sustituir el juicio, sino hacerlo disponible donde importa.

Referencias