¿Cómo conectar los sistemas de la empresa con inteligencia artificial?

Según Mesterséges Intelligencia Központ Kft., empresa de desarrollo de software con sede en Budapest, la manera es integrar el modelo de lenguaje en los flujos de trabajo existentes mediante una API: los sistemas se mantienen, y el modelo extrae, clasifica, resume y redacta.

En resumen: no hace falta sustituir los sistemas existentes: el modelo de lenguaje recibe tareas y datos a través de una interfaz de programación, y el resultado vuelve allí donde se trabaja con él: al CRM, al ERP o al correo electrónico. Conviene empezar con una única tarea bien medible, pasar solo los datos necesarios y, donde un error cuesta dinero, que una persona apruebe el paso.

¿Qué significa esto en la práctica?

El gran modelo de lenguaje (large language model, LLM) interpreta y produce texto. En el uso empresarial no es una ventana de chat aparte en la que los empleados copian y pegan texto, sino un servicio al que los propios programas de la empresa llaman a través de una interfaz de programación, es decir, una API (application programming interface). El modelo recibe los datos que necesita la tarea, realiza el trabajo lingüístico, y el programa lleva el resultado al sistema adecuado, comprobado y registrado.

Hay cinco operaciones lingüísticas que aparecen en casi todas las integraciones:

• Extracción: una factura, un albarán o un correo entrante se convierten en datos estructurados: cliente, partidas, plazo.
• Clasificación: el sistema decide si un correo es una reclamación, una solicitud de oferta o una consulta de facturación, y lo coloca en la cola correspondiente.
• Resumen: el largo intercambio de correos con un cliente se convierte en unos antecedentes de pocas frases en el CRM.
• Redacción: se prepara un borrador de respuesta, el texto de una oferta o una descripción de producto, que revisa un empleado.
• Respuesta: el empleado pregunta en lenguaje cotidiano a los documentos o a los datos de la empresa.

Si el sistema no solo tiene que responder, sino también actuar por sí mismo, en varios pasos, ya se trata de un agente de IA; sobre la diferencia entre ambas soluciones trata el artículo ¿Chatbot o agente de IA?. Si el modelo tiene que responder a partir de los documentos propios de la empresa, el método es RAG, que presentamos en un artículo aparte.

Tres patrones de integración

API y webhook

La mayoría de los sistemas empresariales (CRM, ERP, tienda online, programa de facturación, correo electrónico) disponen de una API a través de la cual otro programa puede leer datos de ellos o escribir datos en ellos. El webhook es lo contrario: el propio sistema avisa a una dirección definida de antemano cuando ocurre algo, por ejemplo, cuando llega un pedido o un correo. La integración de IA más sencilla consta de estos dos elementos: un evento pone en marcha un servicio propio, que llama a la API del modelo de lenguaje, comprueba el resultado y lo escribe en el sistema de destino a través de su API. En este patrón, el modelo no tiene acceso directo a ningún sistema de la empresa; todo lo hace nuestro código, y es ahí donde se decide qué puede llegar al modelo y qué puede volver.

Llamada a funciones (tool use)

La llamada a funciones (en Anthropic, tool use, es decir, uso de herramientas) permite que el modelo decida por sí mismo cuándo necesita un dato o una operación. El desarrollador describe al modelo las funciones disponibles, por ejemplo, «consultar el estado de un pedido», y el modelo, a partir de la pregunta, devuelve una llamada estructurada con los parámetros necesarios. Según la documentación de los tres grandes proveedores, la función no la ejecuta el modelo, sino la aplicación: en la documentación de OpenAI, el código se ejecuta del lado de la aplicación; según Anthropic, las herramientas propias las ejecuta la aplicación; y la documentación de Google Gemini afirma que el modelo no ejecuta la función por sí mismo. De ahí se deriva el principio de diseño más importante: la comprobación de permisos reside en nuestro código y no depende de la buena disposición del modelo. OpenAI y Anthropic también ofrecen un modo estricto (strict), que garantiza que los parámetros de la llamada sigan exactamente el esquema indicado; sin embargo, la documentación de Anthropic también advierte de que, cuando falta información, el modelo a veces inventa un valor que parece razonable, por lo que el código también debe comprobar los parámetros.

Model Context Protocol (MCP)

MCP es un protocolo abierto que, según su especificación, ofrece una forma estándar de conectar las aplicaciones que utilizan modelos de lenguaje con fuentes de datos y herramientas externas. Tiene tres participantes: el anfitrión (host), es decir, la aplicación que utiliza el modelo de lenguaje; el cliente que se ejecuta en ella; y el servidor, que ofrece datos (resources), plantillas de instrucciones (prompts) y herramientas invocables (tools). Los mensajes tienen formato JSON-RPC 2.0; la versión vigente de la especificación es la identificada como 2026-07-28 (comprobado el 17 de octubre de 2026).

La ventaja de MCP es que basta con escribir una vez el servidor de un sistema, y después varias aplicaciones de IA pueden utilizarlo. La API de Anthropic, la API de OpenAI y la API de Gemini pueden conectarse a servidores MCP remotos (comprobado el 17 de octubre de 2026). El protocolo no resuelve todas las cuestiones de seguridad: según los principios de seguridad de la especificación, la aplicación anfitriona debe obtener el consentimiento explícito del usuario antes de cada llamada a una herramienta, pero el propio protocolo no puede imponerlo; debe incorporarlo quien lo implementa. OpenAI también advierte de que un servidor malicioso puede filtrar datos sensibles que entren en el contexto del modelo. Por eso, en un entorno empresarial solo cabe considerar servidores propios o de un proveedor de confianza.

Patrón	Para qué sirve	A qué prestar atención
API y webhook	procesos fijos y predecibles: cada correo y cada factura siguen el mismo camino	hay que planificar de antemano cada paso, incluidos la gestión de errores y los reintentos
Llamada a funciones	cuando el modelo tiene que obtener datos o iniciar una operación en función de la pregunta	el conjunto de funciones y sus permisos; el modelo también puede proporcionar un parámetro erróneo
MCP	cuando varias aplicaciones de IA tienen que acceder al mismo sistema	solo servidores de confianza; aprobación antes de las llamadas a herramientas

¿Para qué se puede usar? Tareas típicas

Área	Tarea	Patrón habitual	Aprobación humana
Documentos	extracción de los datos de facturas, albaranes y contratos, y cotejo con el pedido	API, con salida en un esquema fijo	en caso de discrepancia o de extracción dudosa
Correo electrónico	clasificación y reenvío de los correos entrantes, borrador de respuesta	webhook y API	antes de enviar la respuesta
CRM	resumen del historial del cliente, propuesta del siguiente paso	llamada a funciones con permiso de lectura	no hace falta, porque es solo una propuesta
ERP	preguntas sobre los datos en lenguaje cotidiano, elaboración de informes	llamada a funciones con permiso de lectura	si la operación modificara datos
Tienda online	descripciones de productos, traducción, un buscador más preciso	API	antes de publicar el texto
Conocimiento interno	preguntas y respuestas a partir de normativas internas y manuales	RAG	no hace falta si la respuesta indica la fuente

Encontrará más información sobre nuestros servicios en la página Integración de IA; sobre los procesos automatizados que abarcan varios sistemas, en la página Automatización de procesos; y sobre la IA integrada en los sistemas ERP y CRM, en la página Software empresarial.

Flujo de datos y protección de datos: ¿qué va adónde?

La integración de IA también es tratamiento de datos. Por eso, el primer paso del diseño es un sencillo diagrama del flujo de datos: qué campos salen de los sistemas de la empresa, a qué proveedor llegan, en qué región se tratan, durante cuánto tiempo los almacena el proveedor y qué vuelve. Las condiciones de los proveedores cambian a menudo; lo que sigue se basa en la documentación propia de los proveedores (comprobado el 17 de octubre de 2026).

¿Qué dicen los proveedores?

• OpenAI: según su documentación sobre el tratamiento de datos, los datos enviados a través de la API no se utilizan para entrenar modelos, salvo que el cliente lo consienta expresamente. Los registros de supervisión de abusos se conservan por defecto durante un máximo de 30 días. El almacenamiento y el tratamiento de datos en Europa (EEE y Suiza) están disponibles con una aprobación aparte y con determinadas configuraciones de conservación de datos.
• Anthropic: según su centro de privacidad, las entradas y salidas de sus productos comerciales, incluida la API, por defecto no se utilizan para entrenar modelos y, en el caso de la API, por regla general, se eliminan en un plazo de 30 días, con las excepciones indicadas. En la API propia de Anthropic, el lugar de tratamiento puede ser, según la documentación, «us» o «global»; en Amazon Bedrock y en Google Cloud, la región la determina el punto de conexión (endpoint) elegido.
• Google: según las condiciones de la API de Gemini, en los servicios de pago Google no utiliza las instrucciones (prompts) ni las respuestas para mejorar sus productos, y solo las registra durante un periodo limitado para detectar abusos; a los usuarios del EEE, Suiza y el Reino Unido solo se les pueden ofrecer aplicaciones basadas en los servicios de pago. Según la descripción de la residencia de datos de Vertex AI de Google Cloud, en el punto de conexión multirregional de la UE el tratamiento permanece dentro de la UE, mientras que en el punto de conexión global no existe tal garantía; qué modelo está disponible en qué región varía de un modelo a otro.

Aspectos del RGPD

Si al modelo llegan datos personales, el tratamiento está sujeto al RGPD. En ese caso, el proveedor del modelo suele ser encargado del tratamiento, por lo que con él hace falta un contrato conforme al artículo 28, apartado 3, del Reglamento General de Protección de Datos; el artículo 5 exige la minimización de datos, y el artículo 25 menciona la seudonimización como ejemplo entre los medios de protección de datos desde el diseño. En la práctica, esto significa lo siguiente:

• solo llegan al modelo los campos necesarios para la tarea;
• los nombres y los identificadores, siempre que sea posible, los ocultamos o seudonimizamos, y la respuesta la volvemos a asociar en nuestro propio sistema;
• el modelo solo puede ver lo que también puede ver el usuario que pregunta;
• registramos quién llamó al modelo, cuándo y con qué datos.

Sobre la transferencia de datos fuera de la Unión, la transparencia y el AI Act escribimos en el artículo AI Act y RGPD en un chatbot empresarial. Esto es información, no asesoramiento jurídico.

¿Dónde hace falta aprobación humana?

El modelo de lenguaje puede equivocarse y, según la guía de evaluación de OpenAI, ni siquiera da siempre la misma salida para la misma entrada. Por eso conviene diseñar el proceso de modo que un error del modelo no pueda causar daños. Distinguimos tres niveles:

• Propuesta: el modelo solo propone (resume, redacta un borrador, sugiere una categoría), y la decisión y la operación las realiza una persona. Aquí el coste de un error es bajo.
• Operación preparada: el modelo prepara el paso, por ejemplo rellena la reclamación o redacta la respuesta, y un empleado lo aprueba o lo corrige con un clic.
• Operación automática: el paso se ejecuta sin aprobación, pero solo con permisos limitados, límites de cantidad, registro y comprobaciones por muestreo.

La regla general: donde un error cuesta dinero, afecta a un cliente o no puede deshacerse (un pago, una factura, un contrato, un correo enviado a un cliente), una persona aprueba el paso. La lista de riesgos del OWASP GenAI Security Project dice lo mismo sobre la libertad de acción excesiva (Excessive Agency): el modelo solo recibe las herramientas que necesita para su tarea, con los permisos más limitados posibles; una persona debe aprobar las operaciones de gran impacto; la operación debe ejecutarse con los permisos propios del usuario, y cada paso debe quedar registrado.

Un riesgo aparte es la inyección de prompts (prompt injection): si el modelo lee contenido externo, como un correo entrante, un documento cargado o una página web, este puede contener texto que intente influir en él como si fuera una instrucción. Contra ello, OWASP recomienda el mínimo privilegio necesario, la aprobación humana antes de las operaciones privilegiadas y el tratamiento del contenido externo por separado y marcado como no fiable.

Pruebas y supervisión

Una integración de IA no es buena porque convenza en una demostración, sino porque trabaja bien, de forma medible, con el material real de la empresa. Según la guía de evaluación de OpenAI, los datos de prueba deben incluir casos típicos, extremos y deliberadamente engañosos, y la evaluación debe repetirse con cada cambio; Anthropic recomienda criterios de éxito concretos y medibles y un conjunto de pruebas que refleje las tareas reales. Así lo organizamos nosotros:

• Conjunto de evaluación: muestras reales, anonimizadas si es necesario, con el resultado esperado, por ejemplo, los campos que hay que extraer o la categoría correcta.
• Medición antes de la puesta en producción: comparamos en este conjunto los modelos y los prompts candidatos.
• Nueva medición con cada cambio: con un prompt nuevo, una nueva versión del modelo o un nuevo tipo de documento.
• Registro: la entrada, la salida, el modelo y la versión del prompt, así como la corrección humana; el registro es también la fuente de los siguientes casos de evaluación.
• Supervisión: tasa de errores, proporción de correcciones humanas, tiempo de respuesta y consumo de tokens, con alertas.

Los modelos no son eternos: tanto Anthropic como OpenAI retiran periódicamente los modelos más antiguos y lo notifican con antelación a sus clientes; una solicitud enviada a un modelo retirado devuelve un error. Por eso colocamos el modelo en una capa aparte, y cada cambio de modelo lo medimos con el mismo conjunto de evaluación antes de que pase a producción.

¿Qué modelo elegir?

No hay ningún modelo que sea igual de bueno para todas las tareas, por lo que la elección es cuestión de medición, no de fidelidad a una marca. Nuestros criterios:

• la calidad del texto en húngaro con las propias muestras de la empresa;
• el tipo de tarea: texto, documento escaneado, imagen o tabla;
• la fiabilidad de la llamada a funciones y de la salida estructurada;
• la velocidad y la tarifa de uso con el volumen previsto;
• las condiciones de tratamiento de datos y el lugar del tratamiento;
• la disponibilidad y el ciclo de vida del modelo.

Es habitual que en un mismo sistema trabajen varios modelos: uno más rápido y pequeño para la clasificación, y otro más potente para los textos complejos. Como el modelo está en una capa aparte, la decisión puede modificarse más adelante.

¿De qué depende el coste?

El coste tiene dos partes. El importe del desarrollo se deriva del tamaño funcional, que medimos en puntos de función COSMIC; el método se describe en la página Precios. El coste de funcionamiento depende del uso: los proveedores facturan según la cantidad de texto procesado y generado, es decir, según el número de tokens, y según la descripción de Anthropic, las descripciones de herramientas que se pasan al modelo también cuentan como tokens de entrada. En el coste de funcionamiento influyen:

• el número y la longitud de los documentos y correos procesados;
• cuántas llamadas al modelo requiere un proceso: un agente que trabaja en varios pasos supone varias llamadas;
• el modelo elegido;
• el tamaño del contexto y de las descripciones de herramientas que se pasan al modelo;
• las configuraciones especiales, por ejemplo, el tratamiento con restricción geográfica, que los proveedores pueden facturar con una tarifa más alta.

El coste de funcionamiento lo estimamos durante el diseño con las muestras reales de la empresa, y también lo tenemos en cuenta al elegir el modelo.

Paso a paso: cómo empezar

1. Elegir una tarea: un trabajo frecuente, de carácter lingüístico, con un objetivo medible, por ejemplo, la clasificación de las reclamaciones entrantes.
2. Dibujar el flujo de datos: de dónde vienen los datos, qué puede ir al modelo, adónde va el resultado y quién lo aprueba.
3. Muestras y conjunto de evaluación: ejemplos reales y anonimizados con el resultado esperado.
4. Prototipo: comparación de los modelos candidatos con las muestras, todavía sin conexión real.
5. Conexión: API, webhook, llamada a funciones o MCP, con permisos, gestión de errores y registro.
6. Puesta en producción de prueba: en un círculo reducido, con aprobación humana de cada paso; aprendemos de las correcciones.
7. Ampliación y operación: donde la medición lo justifica, el círculo de aprobación se reduce; la supervisión y los cambios de modelo son continuos.

Errores típicos

• Una ventana de chat en lugar de una integración: los empleados copian datos a mano en una interfaz de IA genérica, de modo que los datos salen de la empresa sin control y nada puede medirse.
• Demasiados permisos: el modelo tiene acceso a todo lo que alcanza la cuenta de integración.
• Sin conjunto de evaluación: sobre la calidad decide la impresión, y sobre el cambio de modelo, las conjeturas.
• El modelo grabado en el código: si el modelo se retira, hay que reescribir toda la integración.
• La protección de datos, al final: el diagrama del flujo de datos y el contrato de encargo del tratamiento son mucho más difíciles a posteriori.
• Todo a la vez: cinco procesos en un mismo proyecto, sin medición; ninguno llega a terminarse de verdad.

Preguntas frecuentes

¿Qué modelo elegir?

El que, con las propias muestras de la empresa, rinde mejor de forma medible en la tarea concreta, con una tarifa aceptable y con condiciones de tratamiento de datos adecuadas. Trabajamos con los modelos de OpenAI, Anthropic y Google, comparamos a los candidatos con los ejemplos de la empresa y, como el modelo está en una capa aparte, la decisión puede modificarse más adelante.

¿Es seguro enviar datos de la empresa a un servicio de IA?

Con un diseño adecuado, sí, pero no por sí solo. Según su propia documentación, las API empresariales de los grandes proveedores no utilizan por defecto los datos enviados para entrenar modelos (comprobado el 17 de octubre de 2026), pero el plazo y el lugar de almacenamiento varían según el proveedor y la configuración. Depende de la empresa que solo salgan los datos necesarios, que los datos personales estén, a ser posible, seudonimizados, y que haya un contrato de encargo del tratamiento y un lugar de tratamiento elegido conscientemente. Esto es información, no asesoramiento jurídico.

¿Hay que sustituir nuestros sistemas existentes?

No. La integración se basa en la API, los webhooks, la base de datos o las exportaciones de archivos de los sistemas existentes, y el resultado vuelve allí donde ya se trabajaba. Si un sistema antiguo no tiene interfaz de programación, estudiamos de qué manera podemos acceder a sus datos de forma segura.

¿Qué es MCP?

Model Context Protocol es un protocolo abierto que conecta de forma estándar las aplicaciones que utilizan modelos de lenguaje con fuentes de datos y herramientas externas. Es útil cuando varias aplicaciones de IA acceden al mismo sistema. En un entorno empresarial, conviene utilizarlo solo con servidores de confianza y con aprobación antes de las llamadas a herramientas.

¿Qué ocurre si la IA se equivoca?

Contamos con ello, por lo que diseñamos el proceso de forma que el error no cause daños. El código comprueba la salida (el esquema y las reglas de negocio, por ejemplo, si el importe total de la factura coincide con la suma de las partidas), una persona aprueba antes del paso arriesgado, los casos dudosos pasan a un empleado y todo queda registrado. Los errores detectados se incorporan al conjunto de evaluación, de modo que la corrección puede medirse.

¿Cómo podemos ayudarle?

Conectamos con inteligencia artificial todo lo que existe: integramos los modelos de lenguaje de OpenAI (ChatGPT), Anthropic (Claude) y Google (Gemini) en los sistemas existentes de las empresas. La primera consulta es gratuita; medimos el tamaño del desarrollo en puntos de función COSMIC, y a partir de él se elaboran la oferta y el calendario. Si lo solicita, firmamos un acuerdo de confidencialidad (NDA) y, tras la entrega, también nos encargamos de la operación y el mantenimiento, incluida la supervisión del funcionamiento del modelo. El código fuente y los derechos de uso se rigen por el contrato.

Encontrará los detalles en la página Integración de IA. Si tiene un proceso que le gustaría conectar con inteligencia artificial, escríbanos a través de los datos de contacto que figuran en la página Contacto.

Fuentes

• OpenAI: Function calling
• OpenAI: Data controls in the OpenAI platform
• OpenAI: MCP servers
• OpenAI: Evaluation best practices
• OpenAI: Deprecations
• Anthropic: Tool use with Claude
• Anthropic: Data residency
• Anthropic: Define success criteria and build evaluations
• Anthropic: Model deprecations
• Anthropic Privacy Center: Is my data used for model training?
• Anthropic Privacy Center: How long do you store my organization's data?
• Google Gemini API: Function calling
• Google: Gemini API Additional Terms of Service
• Google Cloud Vertex AI: Data residency
• Model Context Protocol: Specification, 2026-07-28
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• EUR-Lex: Reglamento (UE) 2016/679 (Reglamento General de Protección de Datos, RGPD)