Tu empresa ya tiene los datos: están en el ERP, en el data warehouse, en hojas de cálculo y en cientos de documentos. El problema es que preguntarles algo sigue dependiendo de alguien que sepa SQL, que arme el reporte o que busque el archivo correcto. Y cuando aparecen los asistentes de IA, surge la duda obvia: ¿cómo le doy acceso a un LLM como Claude o ChatGPT sin subir mis datos a un tercero, sin que la IA invente cifras y sin pasar a llevar la Ley 21.719?
La respuesta técnica más limpia hoy es un servidor MCP. En esta guía explicamos qué es el Model Context Protocol, cómo se conecta un modelo de lenguaje a los datos de una organización de forma controlada y trazable, en qué se diferencia de RAG y fine-tuning, y qué principios legales conviene tener presentes antes de conectar IA a datos personales en Chile.
El problema: datos valiosos a los que nadie puede preguntar en lenguaje natural
La mayoría de las empresas no tiene un problema de falta de datos, sino de acceso. La información está repartida entre el ERP/CRM, un data warehouse en la nube, planillas y documentos, y cada consulta nueva pasa por el equipo de datos o de TI. Eso genera un cuello de botella: decisiones que esperan días por un reporte, y conocimiento que solo extrae quien domina las herramientas.
Conectar un LLM directo a esas fuentes parece la solución, pero abre tres riesgos reales:
- Fuga de datos: copiar la base a una plataforma externa o pegarla en un chat para que el modelo la lea.
- Respuestas inventadas: un modelo que no consulta la fuente real "alucina" cifras que parecen verosímiles.
- Falta de control y trazabilidad: no saber qué datos vio el modelo, quién preguntó qué, ni de dónde salió cada respuesta.
El Model Context Protocol nace precisamente para resolver esos tres puntos sin tener que mover los datos de lugar.
Qué es un servidor MCP (Model Context Protocol)
MCP (Model Context Protocol) es un estándar abierto que conecta modelos de lenguaje con los datos y sistemas de una organización a través de un componente llamado servidor MCP. Ese servidor no entrega la base completa al modelo: expone un conjunto acotado de herramientas y recursos que el modelo puede usar, y nada más.
En la práctica funciona así: el usuario pregunta en lenguaje natural, el modelo decide qué herramienta del servidor invocar (por ejemplo, "consultar transacciones de un período"), el servidor ejecuta esa consulta contra la fuente real y devuelve el resultado. El modelo redacta la respuesta sobre datos verdaderos, no sobre suposiciones. Los datos nunca se copian a otro lugar: viven donde siempre estuvieron y el servidor actúa como intermediario gobernado.
La ventaja frente a una integración hecha a la medida para cada modelo es que MCP es un estándar: el mismo servidor sirve para distintos asistentes. Hoy en Data Inmobiliaria, nuestro producto propio de datos del mercado inmobiliario chileno, operamos un servidor MCP que permite consultar 9,5 millones de propiedades de Chile en lenguaje natural desde Claude o ChatGPT, sin que el usuario escriba una sola línea de SQL.
Un servidor MCP (Model Context Protocol) conecta un LLM como Claude o ChatGPT con tus datos exponiendo herramientas acotadas, sin copiar la información a otro lugar.
Cómo funciona la arquitectura, paso a paso
Una conexión MCP segura se monta sobre la infraestructura que ya tienes, sin reemplazar nada. El flujo típico es:
- 1. Pregunta en lenguaje natural. El usuario conversa con el asistente (Claude o ChatGPT) como lo haría con un analista.
- 2. El modelo elige una herramienta. El servidor MCP publica un catálogo de operaciones permitidas (consultas, búsquedas, lecturas). El modelo no inventa el acceso: solo puede usar lo que el servidor expone.
- 3. El servidor ejecuta la consulta de solo lectura. La operación corre contra el data warehouse, el ERP/CRM o el repositorio documental, dentro de tu entorno.
- 4. Devuelve datos reales. El modelo responde sobre el resultado de la consulta, no sobre su memoria de entrenamiento.
- 5. Se registra todo. Cada consulta queda con su usuario, su hora y su fuente, para auditoría.
El punto clave de diseño es que el control vive en el servidor, no en el modelo. Tú defines qué tablas, qué campos y qué operaciones quedan disponibles; el resto sencillamente no existe para la IA. Lo construimos sobre tecnologías estándar (Python, SQL y tu nube actual, sea AWS, Azure o Google Cloud), reutilizando tu infraestructura en vez de duplicarla.
Por qué es seguro: solo lectura, datos en tu entorno y trazabilidad
"Conectar IA a mis datos" suena riesgoso, pero un servidor MCP bien diseñado invierte la lógica: en lugar de abrirle todo al modelo, le abre solo lo mínimo y de forma controlada. Los pilares de seguridad son cuatro:
- Acceso de solo lectura y acotado. El servidor define qué puede y qué no puede consultar el modelo. No puede modificar, borrar ni ejecutar transacciones: consulta y responde.
- Los datos permanecen en tu entorno. No se copian ni se suben a una plataforma externa para que la IA "aprenda" de ellos. El servidor consulta donde ya están.
- Trazabilidad y auditoría. Cada consulta queda registrada: quién preguntó, cuándo y qué fuente se tocó. Eso te permite verificar de dónde salió cada respuesta.
- El modelo no entrena con tus datos. Los proveedores serios de LLM empresariales no usan los datos del cliente para reentrenar sus modelos. Tu información se usa para responderte en ese momento, no para mejorar el modelo de un tercero.
El resultado práctico lo vemos en el conector de Data Inmobiliaria: millones de registros consultables en lenguaje natural, sin que el usuario acceda directamente a la base ni pueda alterarla.
MCP vs RAG vs fine-tuning: cuál usar y cuándo
Son tres formas distintas de "darle contexto" a un LLM, y se suelen confundir. La diferencia importa porque elegir mal encarece el proyecto o lo hace frágil:
- MCP: el modelo consulta tus datos y sistemas en vivo mediante herramientas controladas. Ideal cuando los datos cambian seguido y necesitas trazabilidad y solo lectura gobernada.
- RAG (Retrieval-Augmented Generation): se recuperan los documentos más relevantes y se inyectan en el contexto del modelo antes de que responda. Encaja muy bien con bases documentales (contratos, manuales, normativa).
- Fine-tuning: se reentrena el modelo con tus datos. Es caro, los datos quedan "congelados" al momento del entrenamiento y desactualizarse implica volver a entrenar.
Como regla general: para datos que cambian y donde necesitas saber de dónde viene cada respuesta, MCP y RAG suelen ganar; muchas veces se combinan (MCP para datos estructurados en vivo, RAG para documentos). El fine-tuning tiene sentido para tono o tareas muy específicas, no para mantener al modelo "al día" con tu información.
Consideraciones legales: la Ley 21.719 al conectar IA a datos
Lo siguiente es orientación general, no asesoría legal: ante datos personales, valida tu caso con tu equipo jurídico. Dicho eso, la Ley 21.719 de Protección de Datos Personales de Chile fija principios que conviene incorporar al diseño desde el inicio:
- Finalidad: los datos se usan para el propósito declarado. Define para qué se conecta la IA y no excedas ese fin.
- Proporcionalidad y minimización: expón al modelo solo los datos necesarios. Un servidor MCP ayuda aquí, porque limita por diseño qué campos quedan visibles.
- Licitud: ten clara la base legal que habilita el tratamiento de esos datos.
- Responsabilidad: registra los accesos y mantén trazabilidad de las consultas, justo lo que entrega la auditoría del servidor.
Lo bueno es que un MCP bien diseñado y los principios de la ley apuntan en la misma dirección: minimizar lo expuesto, controlar accesos y dejar registro. La arquitectura de solo lectura con datos en tu propio entorno es, además, un punto de partida favorable.
Si quieres conectar tus datos a un LLM con este enfoque, lo construimos a medida sobre tu infraestructura actual. Cotiza tu proyecto desde UF 75 y conversemos qué fuentes tiene sentido exponer primero. Cada desarrollo incluye 30 días de garantía post-entrega.
