MCP: cómo exponer una API regulatoria a agentes de IA de forma controlada

Los agentes de IA ya no solo redactan texto: cada vez con más frecuencia consultan sistemas, llenan formularios y preparan expedientes. En cumplimiento regulatorio eso plantea una pregunta concreta: si un agente va a revisar a un cliente o a un proveedor, ¿cómo le damos acceso a una fuente confiable de listas de sanciones sin entregarle más de lo necesario? En este artículo explicamos qué es el Model Context Protocol (MCP), por qué una consulta de cumplimiento encaja bien como herramienta para un agente y qué controles consideramos indispensables.

Qué es MCP

MCP es un protocolo abierto que estandariza la forma en que una aplicación de IA se conecta con sistemas externos. En lugar de que cada asistente, editor de código o plataforma de agentes construya su propia integración para cada servicio, el servicio publica un servidor MCP y cualquier cliente compatible puede usarlo.

Un servidor MCP expone principalmente tres tipos de elementos:

• Herramientas: acciones que el modelo puede invocar, cada una con nombre, descripción y un esquema de parámetros de entrada.
• Recursos: información de contexto que la aplicación puede leer.
• Prompts: plantillas de instrucciones predefinidas.

Para una API regulatoria lo relevante son las herramientas. El modelo lee la descripción, decide cuándo conviene usarla, arma los parámetros y recibe una respuesta estructurada. Quien ejecuta la llamada es la aplicación anfitriona, que además puede pedir confirmación al usuario antes de hacerlo.

Por qué una consulta de cumplimiento es una buena herramienta

No toda API debería exponerse a un agente. Una búsqueda en listas de sanciones tiene características que la hacen especialmente adecuada:

• Es de solo lectura. Buscar un nombre o un RFC en OFAC, en la lista consolidada de la ONU o en las listas del SAT (69, 69-B y 69-B Bis) no modifica nada. Si el agente se equivoca de parámetros, el costo es una consulta de más, no un registro alterado.
• Tiene entradas acotadas. Un nombre o un RFC y, opcionalmente, las listas a consultar. Es fácil describirlo en un esquema y validar lo que llega.
• Devuelve datos estructurados. Coincidencias con su lista de origen, un puntaje de similitud y los datos de la entidad listada. El modelo no tiene que interpretar páginas web ni texto libre.
• Resuelve un paso que se omite con facilidad. En un alta de clientes, la búsqueda en listas es el paso que se olvida cuando depende de abrir varios portales.

Lo que el agente no debe hacer es decidir. Una coincidencia fonética contra una lista no es una determinación de riesgo: puede tratarse de un homónimo, de un registro que ya cambió o de un falso positivo. El agente puede encontrar, ordenar y documentar; la evaluación y la decisión siguen siendo de una persona.

Los controles que no son negociables

Conectar un agente a una fuente regulatoria cambia quién hace la consulta, pero no debe cambiar las reglas. Estos son los controles que aplicamos en nuestra API y que trasladamos sin excepción al canal MCP:

1. Autenticación con llave por cuenta. El agente usa la misma llave de API que cualquier otra integración: emitida para una cuenta concreta y revocable desde el panel. Una llave revocada recibe la misma respuesta que una que nunca existió, de modo que no se puede usar el servicio para averiguar qué llaves son válidas.
2. Separación de credenciales. La llave de API solo permite consultar; no da acceso a la facturación ni a la administración de la cuenta. A la inversa, una sesión del panel no sirve para hacer consultas.
3. Límites de uso. Los límites de tasa por ruta protegen al servicio y también al cliente. Un agente atrapado en un ciclo mal planteado puede generar cientos de llamadas en minutos; el límite convierte ese error en una respuesta de rechazo y no en un consumo descontrolado.
4. Bitácora de cada consulta. Cada búsqueda queda registrada en el historial de la cuenta: qué parámetros se enviaron, qué se respondió, cuándo y con qué llave. Si más adelante hay que demostrar ante un auditor que un cliente fue revisado contra listas, la evidencia no depende de lo que el agente haya conservado en su conversación.
5. Superficie mínima. Al agente solo se le exponen operaciones públicas de consulta. Las funciones internas, administrativas o que modifican datos quedan fuera de su conjunto de herramientas.

Un agente con acceso a una fuente regulatoria debe tener exactamente los mismos permisos, límites y registros que tendría una integración tradicional. Ni uno más.

La persona sigue decidiendo

El diseño que proponemos separa con claridad tres momentos:

• El agente consulta. Ejecuta la búsqueda, reúne las coincidencias y las presenta con su lista de origen.
• La persona evalúa. Revisa si la coincidencia corresponde realmente al cliente, con base en otros datos del expediente: RFC completo, fecha de nacimiento, domicilio, nacionalidad.
• El sistema registra. Tanto la consulta como la decisión quedan documentadas, junto con quién la tomó.

Esto no es una limitación técnica, sino una consecuencia del propio marco regulatorio: la obligación de identificar al cliente y de evaluar su riesgo recae en quien está sujeto a la regulación, no en una herramienta. Un agente bien diseñado acelera el trabajo y reduce omisiones, pero no sustituye ese juicio.

Cómo lo estamos construyendo en AmigoApi

En AmigoApi estamos construyendo un servidor MCP sobre la misma API REST que ya usan nuestros clientes. El principio es sencillo: misma llave, mismos datos, mismo historial, distinta forma de consumo. Las listas que se consultan por MCP son las mismas que se consultan por REST, se sincronizan contra las fuentes oficiales y cada consulta queda en la bitácora de la cuenta. Las operaciones internas no forman parte del conjunto de herramientas.

Mientras el servidor MCP queda disponible, cualquier agente capaz de hacer una llamada HTTP puede usar la API REST directamente, con los mismos controles descritos arriba.

Si estás diseñando un flujo de cumplimiento con agentes de IA y quieres revisar cómo delimitar sus permisos, Escríbenos.