flowchart LR
C[Cliente] --> A[Proveedor de aplicación]
A --> M[Proveedor del modelo]
A --> CL[Cloud / hosting]
A --> DB[Base documental]
A --> OCR[Servicio de OCR]
A --> ID[Servicio de identidad]
A --> LOG[Logging / analytics]
Dependencias
Cómo reconstruir los proveedores, servicios y fuentes de los que depende una aplicación de IA aunque el cliente contrate con una sola contraparte.
Dependencias
El AI Stack nos permitió identificar qué funciones existen dentro de una solución: infraestructura, datos, modelo, adaptación, orquestación, aplicación y gobernanza.
Ahora aparece una pregunta distinta:
¿Quién sostiene cada una de esas funciones?
Una aplicación puede tener una sola marca, una sola interfaz y un solo contrato principal. Eso no significa que exista un solo actor detrás del servicio.
Una plataforma de IA jurídica puede depender simultáneamente de:
proveedor de aplicación
proveedor del modelo
proveedor cloud
bases documentales
servicios externos
subprocesadoresDesde la perspectiva del usuario hay una experiencia unificada.
Desde la perspectiva técnica puede existir una red distribuida de dependencias.
Desde la perspectiva jurídica puede existir una relación contractual principal que descansa sobre múltiples relaciones de segundo nivel.
Idea central
La relación contractual puede ser bilateral mientras la prestación técnica es distribuida.
Por eso no basta identificar con quién firmamos.
Debemos entender qué terceros sostienen materialmente el servicio, qué función cumplen, qué información reciben y qué ocurre si cambian o fallan.
Qué es una dependencia
Para este sitio llamaremos dependencia a un componente, servicio, fuente o actor cuya disponibilidad, comportamiento o continuidad puede afectar de manera material el funcionamiento de la solución que estamos analizando.
Una prueba práctica consiste en preguntar:
Si este elemento desaparece, se degrada o cambia sustantivamente, ¿puede cambiar la prestación que recibimos?
Si la respuesta es sí, probablemente estamos frente a una dependencia que merece atención.
No todas las dependencias tienen la misma importancia.
Un servicio accesorio de analytics puede tener un impacto menor sobre la función jurídica principal. El modelo fundacional o la base documental podrían ser críticos. La tarea no consiste en inventariar cada biblioteca de software, sino en identificar dependencias materiales para la funcionalidad, los datos, la seguridad, la continuidad, el costo o el cumplimiento.
La experiencia visible puede ocultar una red
Supongamos que una firma contrata una plataforma llamada LexContract AI.
El usuario ve algo simple:
LexContract AI
[ Subir contrato ]
[ Revisar ]
[ Exportar matriz ]Pero la arquitectura podría ser:
El cliente puede tener contrato solamente con el proveedor de aplicación.
Los demás actores pueden encontrarse jurídicamente detrás de esa relación.
La interfaz unifica la experiencia. No elimina las dependencias.
1. Proveedor de aplicación
Es normalmente la contraparte más visible.
Puede controlar:
- interfaz;
- gestión de usuarios;
- configuración;
- funcionalidades;
- integración;
- soporte;
- facturación;
- documentación del producto.
En un servicio SaaS suele ser también quien mantiene la relación principal con el cliente.
El error frecuente
Asumir que el proveedor de aplicación también desarrolla y controla todos los componentes subyacentes.
Puede no hacerlo.
Un proveedor jurídico especializado podría concentrar su valor en:
experiencia jurídica
+
workflow
+
fuentes
+
interfaz
+
integraciónmientras consume de terceros:
modelo
+
cloud
+
OCR
+
servicios de identidadEso no vuelve inferior al producto. Muchas arquitecturas modernas se construyen precisamente mediante especialización.
Lo que cambia es el análisis de riesgo.
Preguntas iniciales
¿Qué componentes controla directamente el proveedor?
¿Qué componentes obtiene de terceros?
¿Qué dependencias son críticas para cumplir su promesa contractual?
¿Puede sustituirlas unilateralmente?
2. Proveedor del modelo
Muchas aplicaciones actuales no desarrollan desde cero el modelo fundacional que utilizan.
Consumen un modelo de un tercero mediante algún mecanismo técnico de acceso.
Eso crea una cadena:
CLIENTE
↓
PROVEEDOR DE APLICACIÓN
↓
PROVEEDOR DEL MODELOEl cliente puede no tener contrato directo con el proveedor del modelo.
Sin embargo, la calidad, disponibilidad o continuidad de la aplicación puede depender parcialmente de él.
Qué puede cambiar
Un proveedor de aplicación puede:
- utilizar una nueva versión del mismo modelo;
- sustituir el modelo por otro;
- utilizar modelos diferentes según la tarea;
- incorporar un fallback;
- cambiar de proveedor de modelo.
Estas decisiones pueden modificar:
- calidad;
- comportamiento;
- latencia;
- costos;
- modalidades disponibles;
- localización o flujo de datos;
- restricciones técnicas.
La misma interfaz puede seguir mostrando el mismo botón “Revisar”.
La prestación subyacente puede haber cambiado.
Una pregunta contractual particularmente importante
¿Qué nivel de libertad tiene el proveedor para cambiar el modelo y qué ocurre si ese cambio afecta materialmente la funcionalidad?
No siempre será razonable exigir consentimiento previo para cualquier actualización. En servicios dinámicos, esa exigencia podría ser impracticable.
Pero entre “el proveedor nunca puede cambiar nada” y “el proveedor puede cambiar cualquier componente sin consecuencias” existe un amplio espacio contractual:
- aviso;
- documentación;
- equivalencia funcional;
- requisitos mínimos;
- derecho de evaluación;
- derecho de salida ante cambios materiales.
3. Cloud
La infraestructura cloud puede sostener una parte sustantiva de la prestación.
Puede alojar:
- aplicación;
- bases de datos;
- almacenamiento documental;
- procesamiento;
- servicios de inferencia;
- backups;
- monitoreo.
Desde la perspectiva del cliente, el proveedor cloud puede ser invisible.
Desde la perspectiva operacional, puede ser crítico.
Por qué importa
Dovgalenko muestra que las decisiones de cloud afectan elementos como:
- localización;
- redundancia;
- disaster recovery;
- ambientes de prueba;
- costos de operación.
Esto significa que la pregunta “¿en qué nube corre?” no es meramente técnica.
Puede estar conectada con:
- seguridad;
- residencia de datos;
- continuidad;
- TCO;
- recuperación;
- subcontratación.
Una distinción útil
No debemos confundir:
servicio cloud
con
control efectivo por parte del cliente.
Un proveedor puede utilizar una infraestructura “privada” desde su propia perspectiva y, sin embargo, el cliente no tener control directo sobre ella.
La pregunta debe formularse desde la relación concreta:
¿Quién administra la infraestructura y qué control real tiene nuestra organización?
4. Bases documentales
Las aplicaciones jurídicas tienen una dependencia adicional especialmente importante: las fuentes de información jurídica y documental.
Una herramienta puede depender de:
- legislación;
- jurisprudencia;
- doctrina;
- bases comerciales;
- documentos internos;
- políticas;
- repositorios del cliente;
- fuentes públicas.
Esta dependencia puede afectar directamente la calidad sustantiva del trabajo.
Un ejemplo
Una aplicación promete responder preguntas sobre jurisprudencia chilena.
El modelo lingüístico puede ser excelente.
Pero la utilidad real dependerá también de:
- qué corpus está disponible;
- qué tribunales cubre;
- con qué retraso se actualiza;
- cómo se identifican documentos;
- si existen metadatos fiables;
- si el sistema puede mostrar la fuente.
Un modelo muy capaz conectado a una base incompleta sigue produciendo un sistema con cobertura incompleta.
Por qué esta dependencia es particularmente jurídica
La historia de la informática jurídica muestra que el problema de organizar, representar y recuperar información jurídica antecede ampliamente a la IA generativa contemporánea. Las bases documentales y los sistemas de recuperación han sido durante décadas una infraestructura esencial del trabajo jurídico digital.
La llegada de los LLM no elimina ese problema.
Lo reconfigura.
Ahora una interfaz conversacional puede hacer menos visible la base de información que sostiene la respuesta, lo que aumenta la importancia de preguntar por procedencia y cobertura.
Preguntas iniciales
¿Qué universo documental cubre la herramienta?
¿Quién proporciona el contenido?
¿Con qué frecuencia se actualiza?
¿Puede el proveedor perder la licencia o cambiar la fuente?
¿La procedencia de una respuesta puede reconstruirse?
5. Servicios externos
Además de modelo, cloud y bases documentales, una aplicación puede depender de servicios especializados.
Ejemplos:
OCR
traducción
autenticación
correo
almacenamiento
búsqueda
analytics
monitorización
procesamiento de archivosNo tiene sentido convertir la revisión jurídica en un inventario de toda dependencia técnica de baja relevancia.
Por eso necesitamos un criterio de materialidad.
Un servicio externo merece especial atención cuando puede afectar de manera relevante:
- información confidencial;
- datos personales;
- disponibilidad;
- funcionalidad principal;
- seguridad;
- capacidad de salida;
- cumplimiento regulatorio;
- costos significativos.
Dependencia funcional y dependencia de datos
Dos servicios pueden tener la misma importancia técnica y riesgos jurídicos diferentes.
Un servicio de OCR podría ser crítico para extraer el texto de un PDF.
Un servicio de analytics podría recibir menos contenido sustantivo, pero procesar identificadores de usuarios.
Para entender el sistema necesitamos preguntar dos cosas separadas:
¿Qué función cumple?
¿Qué información recibe?
6. Subprocesadores
Aquí aparece una distinción que debe mantenerse con especial cuidado.
Dependencia técnica ≠ subprocesador.
El concepto de subprocesador responde a una relación jurídica concreta en materia de tratamiento de datos personales. No todo tercero técnicamente relevante será necesariamente un subprocesador, y un tercero que actúa como subprocesador puede cumplir una función técnica poco visible para el usuario.
Por eso conviene mantener dos mapas:
flowchart LR
A[Mapa técnico] --> B[Quién sostiene la prestación]
C[Mapa de datos] --> D[Quién recibe o trata qué información]
Los mapas pueden solaparse, pero no deben confundirse.
Ejemplo
Una base pública de legislación puede ser una dependencia informacional importante y no necesariamente involucrar tratamiento de datos personales del cliente.
Un proveedor cloud puede ser simultáneamente:
- dependencia de infraestructura;
- receptor de datos;
- actor relevante en la cadena de tratamiento.
Un servicio de telemetría puede no afectar directamente el resultado jurídico, pero sí recibir información sobre usuarios o comportamiento de la aplicación.
La calificación jurídica depende de la actividad concreta, no de la posición visual del actor dentro del diagrama.
La dependencia no es un defecto
Conviene evitar una conclusión equivocada.
Una arquitectura con terceros no es necesariamente peor que una arquitectura propia.
La especialización puede mejorar:
- seguridad;
- disponibilidad;
- calidad;
- escalabilidad;
- velocidad de desarrollo;
- costo.
El problema no es “tener dependencias”.
El problema es desconocerlas o no gobernarlas de acuerdo con su criticidad.
Una arquitectura bien gestionada puede incluir múltiples terceros, redundancia y mecanismos claros de sustitución.
Una arquitectura aparentemente simple puede depender críticamente de un único componente sin alternativa.
Por eso conviene evaluar al menos cuatro propiedades.
Cuatro propiedades de una dependencia material
1. Función
¿Qué hace este componente?
No podemos evaluar su importancia si no conocemos su función.
2. Criticidad
¿Qué ocurre si falla?
Puede existir:
- degradación menor;
- pérdida de una funcionalidad;
- interrupción completa;
- pérdida o inaccesibilidad de datos.
3. Control
¿Quién puede configurarlo, modificarlo o sustituirlo?
Esta pregunta permite distinguir dependencia técnica de capacidad real de gestión.
4. Sustituibilidad
¿Puede reemplazarse sin alterar materialmente el servicio?
Una dependencia fácilmente sustituible plantea un riesgo distinto de una dependencia que produce lock-in técnico o contractual.
Podemos reunirlo así:
| Dependencia | Función | Criticidad | Quién controla | Sustituibilidad |
|---|---|---|---|---|
| Modelo | generación/análisis | alta | proveedor aplicación / tercero | media |
| Cloud | hosting | alta | proveedor | baja/media |
| Base jurídica | fuentes | alta | proveedor/licenciante | media |
| OCR | extracción | media | proveedor | alta |
| Analytics | telemetría | baja para función / variable para datos | proveedor | alta |
La tabla es un ejemplo, no una valoración universal.
El riesgo del cambio invisible
Las dependencias adquieren especial importancia durante la vigencia del servicio.
Imaginemos:
DÍA 1
Aplicación → Modelo A → Cloud X
DÍA 250
Aplicación → Modelo B → Cloud X
DÍA 500
Aplicación → Modelo B → Cloud YPara el usuario el producto puede conservar:
- mismo nombre;
- misma URL;
- mismos botones;
- misma factura.
Sin embargo, la arquitectura cambió dos veces.
Esos cambios pueden alterar:
- rendimiento;
- ubicación de datos;
- seguridad;
- continuidad;
- costos internos;
- obligaciones regulatorias;
- comportamiento observable.
Por eso “actualización de producto” y “cambio de dependencia” no son exactamente lo mismo.
Gobernar el cambio
Una relación contractual madura puede necesitar distinguir:
cambio menor
↓
no requiere intervención
cambio relevante
↓
notificación
cambio material
↓
evaluación / remedio / derecho de salidaNo existe un umbral universal.
La importancia depende del tipo de servicio y del riesgo de la organización.
Dependencias y SLA
Una promesa de disponibilidad puede parecer clara:
“99,9 % de uptime mensual.”
Pero debemos preguntar qué mide exactamente.
¿La interfaz web responde?
¿La función de generación está operativa?
¿La base documental está disponible?
¿Se excluyen interrupciones de proveedores externos?
¿Se consideran mantenimientos?
Un SLA puede ser formalmente preciso y sustantivamente insuficiente si su objeto está mal definido.
Esta es una de las razones por las cuales comprender la cadena de dependencias mejora la lectura contractual.
Dependencias y continuidad
La continuidad no consiste solamente en que el proveedor tenga backups.
También puede requerir preguntar:
- ¿qué ocurre si el proveedor del modelo retira el servicio?;
- ¿existe un modelo sustituto?;
- ¿qué ocurre si se pierde la licencia de una base jurídica?;
- ¿pueden exportarse datos?;
- ¿la configuración es portable?;
- ¿existen formatos propietarios?;
- ¿hay asistencia de transición?;
- ¿qué partes del sistema pueden operar durante una degradación?
Tollen analiza mecanismos de continuidad, transition assistance y otras respuestas contractuales frente a dependencia tecnológica. El principio general que debemos conservar es que una solución no debe evaluarse solamente por su entrada al servicio, sino también por cómo se mantiene y cómo se abandona.
Lock-in: cuando una dependencia se vuelve difícil de sustituir
El lock-in aparece cuando reemplazar un proveedor o componente resulta costoso, lento o materialmente disruptivo.
Puede provenir de distintas fuentes:
Lock-in de datos
Información difícil de exportar o reutilizar.
Lock-in de integración
La organización construyó múltiples procesos alrededor de una interfaz específica.
Lock-in de conocimiento
Configuraciones, prompts, reglas o metodologías quedan encerradas en el producto.
Lock-in contractual
Plazos, cargos de término o restricciones dificultan cambiar de proveedor.
Lock-in organizacional
Los usuarios dependen de la herramienta y la organización ha perdido capacidad alternativa.
Una dependencia no necesita ser jurídicamente exclusiva para generar lock-in práctico.
Caso conductor: reconstruir la red antes de aprobar
Volvamos a la pregunta:
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
Antes de entrar a cláusulas específicas reconstruimos una matriz mínima.
| Actor o dependencia | Qué función cumple | Qué información recibe | Qué pasa si falla | Quién puede sustituirlo |
|---|---|---|---|---|
| Proveedor de aplicación | servicio principal | contratos y usuarios | interrupción general | cliente mediante migración |
| Proveedor de modelo | análisis/generación | contexto enviado | degradación o pérdida de IA | proveedor de aplicación |
| Cloud | hosting | documentos y datos operacionales | indisponibilidad | proveedor, con costo |
| Base documental | fuentes jurídicas | consultas | respuestas incompletas | proveedor |
| OCR | extracción | documentos | errores de lectura | proveedor |
Ahora podemos formular preguntas contractuales mucho más concretas:
¿Qué dependencias son subcontratadas?
¿Cuáles son subprocesadores?
¿Qué cambios deben notificarse?
¿El SLA cubre la cadena completa o sólo parte de ella?
¿Existe continuidad ante la caída de un tercero?
¿Puede exportarse la información si termina la relación?
¿Qué nivel de cambio puede ocurrir sin consentimiento?
La arquitectura técnica se ha convertido en una lista de preguntas jurídicamente accionables.
Un mapa mínimo que conviene pedir o construir
Para servicios relevantes, una organización debería poder reconstruir, al menos conceptualmente:
CLIENTE
↓
PROVEEDOR PRINCIPAL
├── modelo(s)
├── cloud
├── fuentes
├── servicios críticos
└── subprocesadoresNo necesitamos exigir un diagrama exhaustivo de cada microservicio.
Necesitamos visibilidad suficiente para comprender:
- criticidad;
- datos;
- continuidad;
- cambio;
- sustitución.
Qué debemos retener
El proveedor con quien firmamos puede no controlar todas las capas del sistema.
La prestación puede depender de:
- proveedor de aplicación;
- proveedor del modelo;
- infraestructura cloud;
- bases documentales;
- servicios externos;
- actores que además pueden tener roles en el tratamiento de datos.
La tarea jurídica consiste en reconstruir cuáles de estas dependencias son materiales y cómo se gobiernan.
La regla principal es:
No confunda simplicidad comercial con simplicidad técnica.
Una sola experiencia de usuario puede ocultar una cadena compleja de proveedores y servicios.
El problema que todavía queda abierto
Ya podemos entender el objeto, descomponerlo en capas y reconstruir quién sostiene esas capas.
Ahora debemos escoger cómo queremos obtener la capacidad.
¿Contratamos una aplicación SaaS completa?
¿Consumimos un modelo por API?
¿Utilizamos una función ya incorporada en nuestro software?
¿Desplegamos componentes bajo mayor control interno?
¿Construimos una solución propia?
¿Combinamos varias estrategias?
La siguiente página cierra esta primera macrosección con esa decisión:
Comprar y gobernar IA.