flowchart LR
A[Aplicación de IA] --> C[Connector]
C --> API[API / interfaz del sistema]
API --> S[Sistema externo]
S --> API
API --> C
C --> A
Connectors
Qué aporta una integración preparada entre una aplicación de IA y sistemas externos, y cómo distinguir conexiones con aplicaciones, repositorios, DMS, correo, calendario y sistemas internos.
Ya sabemos que una tool puede apoyarse en una API para consultar o modificar otro sistema.
Eso resuelve el problema conceptual, pero no elimina el trabajo técnico.
Para conectarse a un DMS, una aplicación puede necesitar conocer sus endpoints, formatos, métodos de autenticación, permisos, errores, límites y cambios de versión. Lo mismo ocurre con correo, calendario, CRM, repositorios y sistemas internos.
Si cada integración debe construirse desde cero, el esfuerzo puede crecer rápidamente.
Por eso aparece otra capa: el connector.
Idea central
En el marco pedagógico de este handbook, un connector es una integración ya preparada que facilita la conexión entre una aplicación y un sistema externo.
Una API dice, en términos generales:
“Ésta es la interfaz mediante la cual puedes interactuar conmigo.”
Un connector añade:
“La integración necesaria para utilizar determinadas capacidades ya está construida.”
Una aclaración terminológica
La palabra connector no tiene un significado universal único.
Según el proveedor, pueden encontrarse términos como:
- connector;
- integration;
- plugin;
- app;
- adapter;
- extension.
No debemos asumir que todos designan exactamente el mismo objeto.
En este curso utilizamos “connector” de manera funcional para representar una capa de integración preparada.
Lo importante no es memorizar la etiqueta comercial.
Lo importante es poder preguntar:
¿qué sistema conecta, qué capacidades expone y bajo qué identidad y permisos?
De la API al connector
Supongamos que una organización quiere que su aplicación jurídica consulte un DMS.
Sin connector podría tener que desarrollar:
autenticación
manejo de tokens
requests
responses
mapeo de campos
tratamiento de errores
control de rate limits
renovación de credenciales
compatibilidad de versionesCon un connector, gran parte de ese trabajo puede venir resuelto o abstraído.
La aplicación podría recibir directamente capacidades como:
buscar_documentos
obtener_archivo
crear_borradorEl connector puede utilizar por debajo una API, pero presenta una integración más preparada para el caso de uso.
Connector ≠ API
Podemos fijar la distinción con una comparación sencilla.
| API | Connector |
|---|---|
| Interfaz técnica que un sistema expone | Integración construida para utilizar determinadas capacidades de ese sistema |
| Define cómo solicitar operaciones | Implementa o abstrae parte de esa comunicación |
| Puede ser muy amplia | Puede exponer un subconjunto concreto |
| Requiere integración | Reduce trabajo de integración |
| No determina por sí sola experiencia de uso | Puede venir integrada a una aplicación concreta |
Una aplicación puede construir varios connectors sobre una misma API.
Y un connector puede, en algunos casos, combinar más de una API o mecanismo técnico.
Aplicaciones
La primera categoría es la integración con otras aplicaciones.
Una aplicación jurídica basada en modelos podría conectarse con:
CRM
procurement
gestor de tareas
sistema financiero
plataforma de firma
Legal OperationsLa palabra “conectarse” sigue siendo demasiado amplia.
Por ejemplo, un connector con un CRM podría permitir únicamente:
consultar_clienteO también:
crear_nota
actualizar_estado
generar_tareaSon capacidades diferentes.
Por eso nunca debemos convertir:
“existe connector con CRM”en:
“la IA puede hacer cualquier cosa en el CRM”Repositorios
Los repositorios son especialmente importantes porque permiten acceder a conocimiento organizacional.
Sin integración, un flujo podría ser:
usuario abre repositorio
↓
busca documento
↓
descarga archivo
↓
abre aplicación de IA
↓
sube archivo
↓
solicita análisisCon un connector:
usuario solicita análisis
↓
aplicación consulta repositorio autorizado
↓
recupera documento
↓
lo incorpora a la tareaLa diferencia no es sólo de comodidad.
También puede mejorar la procedencia de la información.
En vez de recibir un archivo aislado llamado:
contrato_final_final2.pdfla aplicación puede conservar:
identificador
ubicación
versión
fecha
propietario
estadoEsa metadata puede ser muy importante para decidir si un documento es realmente el vigente.
DMS: un caso particularmente relevante para Derecho
Un Document Management System o DMS puede almacenar:
- contratos;
- anexos;
- escritos;
- memorandos;
- versiones;
- correspondencia;
- documentos de clientes;
- metadatos.
Una integración con DMS puede ser extremadamente útil en trabajo jurídico.
Pero también exige un análisis cuidadoso.
La pregunta equivocada
¿La IA tiene acceso al DMS?Es demasiado general.
Preguntas mejores
¿con qué identidad se conecta?
¿qué carpetas puede consultar?
¿hereda permisos del usuario?
¿usa una cuenta de servicio?
¿puede buscar en todos los matters?
¿puede crear documentos?
¿puede reemplazarlos?
¿puede eliminarlos?
¿puede modificar permisos?La integración puede ser técnicamente correcta y, aun así, estar mal gobernada.
El problema de la identidad
Supongamos que el usuario A sólo tiene permiso para ver el matter ACME.
El connector se autentica mediante una cuenta técnica que, por comodidad, puede leer todos los matters.
Entonces aparece una diferencia entre:
PERMISOS DEL USUARIO
matter ACMEy:
PERMISOS DE LA INTEGRACIÓN
repositorio completoSi la aplicación no vuelve a aplicar la autorización adecuada, el connector puede convertirse en una vía para ampliar indebidamente el acceso.
Por eso la identidad técnica de la integración es una cuestión jurídica y de seguridad, no un detalle irrelevante de implementación.
Correo
El correo permite mostrar muy bien por qué “tener un connector” dice poco sobre el poder real del sistema.
Una integración podría permitir:
buscar_correos
leer_hilo
obtener_adjuntos
crear_borrador
enviar_correo
eliminar_mensajeCada operación tiene un efecto distinto.
Leer correo
Puede permitir recuperar antecedentes relevantes para una negociación.
Pero también puede exponer:
- información confidencial;
- datos personales;
- conversaciones internas;
- estrategias;
- comunicaciones de otros asuntos.
Crear borrador
El sistema puede preparar:
Borrador de correo al proveedorsin enviarlo.
Existe un punto claro de revisión humana.
Enviar correo
La operación:
enviar_correo(...)cruza una frontera.
La comunicación llega efectivamente a un tercero.
El connector es el mismo sistema de integración, pero las tools que expone pueden tener riesgos radicalmente distintos.
Calendario
El calendario permite repetir la misma distinción.
Un connector podría exponer:
consultar_disponibilidad
listar_eventos
crear_evento
modificar_evento
cancelar_eventoDecir:
“la aplicación puede usar el calendario”
no permite saber qué nivel de autoridad operacional posee.
Consultar disponibilidad puede ser relativamente acotado.
Cancelar reuniones de terceros puede tener consecuencias mucho mayores.
Sistemas internos
Las organizaciones suelen tener sistemas que no son productos públicos ni plataformas generales.
Por ejemplo:
base de excepciones contractuales
sistema de conflictos
registro de proveedores
portal interno de aprobación
matriz de compliance
base de investigaciones
sistema de gestión de casosTambién pueden conectarse mediante adapters o connectors propios.
Aquí el diseño puede ser incluso más importante porque la organización controla ambas partes de la integración y puede definir exactamente qué capacidades exponer.
Un connector bien diseñado debería ser acotado
Supongamos que el DMS permite:
buscar
leer
crear
mover
compartir
eliminar
cambiar propietario
cambiar permisosNuestro caso de uso sólo necesita:
buscar contratos
leer anexosNo existe una razón automática para que el connector exponga el resto.
Una arquitectura más gobernable podría ofrecer solamente:
buscar_documentos_contractuales
obtener_documento_contractualEsto aplica un principio de menor privilegio desde el propio diseño de integración.
Connector ≠ permiso general
Ésta es la distinción más importante de la página.
La existencia de una conexión no responde todavía:
quién puede utilizarla
qué operaciones están habilitadas
sobre qué recursos
para qué finalidad
con qué límites
Conectividad no equivale a autorización
Un connector crea un camino técnico.
La autorización determina quién puede recorrerlo, hasta dónde y para hacer qué.
No debemos convertir una integración técnica en un permiso universal.
Conectores y transmisión de información
En trabajo jurídico también debemos observar la dirección del flujo.
No toda integración consiste en “traer datos hacia la IA”.
Podemos tener:
SISTEMA INTERNO
↓
APLICACIÓN DE IApero también:
APLICACIÓN DE IA
↓
SISTEMA EXTERNOY, en muchos casos:
ida y vueltaEsto importa para privacidad, confidencialidad y seguridad.
Una integración con correo, por ejemplo, puede permitir que contenido interno termine incluido en una comunicación externa.
Una integración con un servicio de terceros puede implicar transferencia de información fuera del entorno organizacional.
La arquitectura debe hacer visible el flujo.
Un diagrama mínimo
El connector no necesariamente reemplaza la API.
Puede apoyarse en ella.
Su función es reducir la complejidad de integración y presentar capacidades utilizables por la aplicación.
Caso conductor: connector del DMS
Nuestro sistema debe encontrar el anexo de seguridad de ACME.
La aplicación dispone de:
Tool:
buscar_documentosEsa tool utiliza:
Connector:
DMS corporativoEl connector utiliza por debajo:
API del DMSLa petición se autentica con la identidad correspondiente.
El DMS verifica acceso.
La response vuelve al connector.
El connector normaliza la información y la entrega a la tool.
El modelo recibe:
DOC-021 | Anexo de seguridad | firmado | 2026Podemos representar la cadena así:
flowchart LR
M[Modelo] --> T[Tool<br/>buscar_documentos]
T --> C[Connector<br/>DMS]
C --> A[API]
A --> D[DMS]
D --> A
A --> C
C --> T
T --> M
Cada capa responde una pregunta distinta.
El problema de muchas conexiones
Hasta aquí un connector parece resolver bastante bien el problema.
Pero imaginemos que tenemos:
5 aplicaciones de IAy:
20 sistemas externosSi cada combinación necesita su propia integración, podríamos terminar manteniendo una gran cantidad de conexiones especiales.
Este es el problema que conduce al siguiente concepto.
Necesitamos preguntarnos si existe una forma común de exponer tools y recursos para que distintas aplicaciones puedan utilizarlos sin construir una integración completamente nueva para cada pareja.
Consulta en vivo y sincronización no son exactamente lo mismo
Una integración puede funcionar de maneras diferentes.
En un patrón, la aplicación consulta el sistema original en el momento de la tarea:
pregunta
↓
consulta al sistema fuente
↓
respuesta actualEn otro, el connector puede sincronizar información previamente hacia un índice o repositorio intermedio:
sistema fuente
↓
sincronización periódica
↓
índice propio
↓
consulta posteriorAmbas arquitecturas pueden describirse comercialmente como “conectadas”.
Pero plantean preguntas distintas.
En consulta en vivo importa, por ejemplo, la disponibilidad del sistema fuente y la autorización en cada llamada.
En sincronización importa además:
frecuencia de actualización
qué datos se copian
dónde quedan almacenados
qué ocurre al borrar el original
cómo se propagan cambios de permisosNo necesitamos elegir aquí una arquitectura correcta universal. Lo importante es no asumir que “connector” significa necesariamente acceso directo y en tiempo real.
La sincronización puede crear una nueva copia de los datos
Este punto es especialmente relevante en contextos jurídicos.
Si el connector copia documentos desde el DMS hacia otro índice para facilitar búsqueda, ahora existen al menos dos ubicaciones:
DMS original
+
índice o repositorio de la aplicaciónEso puede afectar preguntas sobre:
- retención;
- eliminación;
- seguridad;
- segregación;
- actualización;
- acceso;
- continuidad.
La arquitectura de integración se convierte entonces en arquitectura de datos.
Los connectors también tienen ciclo de vida
Una integración puede dejar de funcionar aunque el modelo no haya cambiado.
Puede ocurrir porque:
la API cambia
la credencial expira
el proveedor modifica permisos
el sistema conectado cambia de versión
una organización revoca accesoPor eso los connectors requieren mantenimiento.
Una aplicación profesional debería poder detectar y comunicar estos fallos sin convertirlos silenciosamente en conclusiones como:
“No se encontró el documento”cuando en realidad ocurrió:
“El connector perdió acceso al repositorio”La diferencia es material.
Integración funcional y dependencia contractual
Un connector también crea una dependencia.
Si una función crítica del producto depende de que continúe operando la integración con un tercero, debemos preguntar qué ocurre si esa integración se rompe.
En procurement pueden ser relevantes cuestiones como:
compatibilidad
cambios de API
soporte
responsabilidad por integración
continuidad
migraciónEl connector no es sólo una comodidad de interfaz. Puede convertirse en una parte esencial de la prestación contratada.
Qué debes recordar
Un connector es una integración preparada con un sistema.
Puede facilitar acceso a:
APLICACIONES
CRM, procurement, Legal Ops
REPOSITORIOS
bases documentales y de conocimiento
DMS
documentos y metadatos
CORREO
lectura, borrador, envío
CALENDARIO
consulta y acciones
SISTEMAS INTERNOS
registros y plataformas propiasLa palabra connector no dice por sí sola qué capacidades están habilitadas.
Siempre debemos preguntar por operaciones, identidad, alcance y permisos.
El problema que todavía queda abierto
Los connectors reducen el trabajo de integración, pero pueden seguir siendo específicos para cada combinación de aplicación y sistema.
Cuando el número de aplicaciones y herramientas crece aparece un problema de interoperabilidad.
El siguiente nodo introduce MCP — Model Context Protocol—, una forma común de exponer tools, resources y prompts a aplicaciones basadas en modelos.