flowchart TB
N[Necesidad: revisión contractual]
N --> S[SaaS jurídico]
N --> A[API + aplicación propia]
N --> F[Feature embebida]
N --> H[Self-hosted]
N --> D[Desarrollo/configuración]
N --> C[Arquitectura híbrida]
Comprar y gobernar IA
SaaS, API, funcionalidades embebidas, self-hosting, desarrollo e implementaciones híbridas: cómo elegir una modalidad según control, riesgo, costo y capacidad interna.
Comprar y gobernar IA
Las cinco páginas anteriores construyeron un mapa.
Ya sabemos distinguir el modelo del sistema y de la aplicación. Sabemos que la operación real es sociotécnica. Podemos descomponer la arquitectura mediante un AI Stack y podemos reconstruir las dependencias que sostienen la prestación.
Ahora aparece una pregunta diferente:
¿Cómo queremos obtener esa capacidad?
Una organización que desea utilizar IA para revisar contratos podría resolver el mismo problema mediante arquitecturas comerciales muy distintas.
Puede contratar una plataforma terminada. Puede consumir un modelo mediante API y construir encima. Puede activar una funcionalidad de IA dentro de un software que ya utiliza. Puede desplegar componentes bajo infraestructura más controlada. Puede contratar desarrollo o configuración a medida. Puede combinar varias alternativas.
Todas estas estrategias pueden ser descritas informalmente como:
“usar IA para revisar contratos”.
Pero distribuyen de manera distinta el trabajo, el control, el riesgo y el costo.
Idea central
La modalidad de adquisición no determina solamente cómo se paga.
Determina también quién construye, integra, opera, actualiza, mide, protege y mantiene cada parte del sistema.
Por eso la pregunta correcta no es simplemente:
“¿comprar o construir?”
En muchos casos será:
“¿qué conviene comprar, qué conviene controlar y qué conviene combinar?”
Antes de elegir una modalidad: definir el problema
Uno de los riesgos clásicos de procurement tecnológico es empezar mirando productos antes de comprender suficientemente la necesidad.
Matthew Reynolds estructura la adquisición de sistemas complejos partiendo precisamente desde el problema, los requerimientos funcionales, la forma de la solución y el costo total. Dovgalenko, desde procurement, también conecta estrategia, cloud, build-or-buy y TCO.
Para IA conviene comenzar con una pregunta operacional:
¿Qué trabajo queremos mejorar y bajo qué restricciones?
No:
“Queremos usar inteligencia artificial.”
Sino, por ejemplo:
“Queremos reducir el tiempo de primera revisión de contratos de proveedores, manteniendo revisión humana para desviaciones relevantes, sin enviar determinada información fuera de entornos autorizados y conservando evidencia suficiente de cada hallazgo.”
La segunda formulación ya contiene variables de diseño.
Permite evaluar modalidades.
Una necesidad, varias arquitecturas
Para esa misma tarea podríamos imaginar:
La tarea es la misma.
La distribución de responsabilidades cambia.
1. SaaS
SaaS significa Software as a Service.
En términos simples, el cliente utiliza una aplicación operada por el proveedor, normalmente de manera remota y mediante una interfaz web u otro cliente.
La arquitectura puede representarse así:
flowchart LR
U[Usuario] --> A[Aplicación del proveedor]
A --> S[Infraestructura y servicios gestionados]
El proveedor asume una parte importante de la operación técnica.
El cliente consume una funcionalidad.
Ejemplo jurídico
Una plataforma permite:
- subir contratos;
- extraer cláusulas;
- generar una matriz de riesgos;
- comparar contra un playbook;
- exportar un informe.
La organización no desarrolla la interfaz ni administra directamente buena parte de la infraestructura.
Qué suele ganar el cliente
- velocidad de adopción;
- menor esfuerzo de desarrollo;
- mantenimiento delegado;
- actualizaciones gestionadas por el proveedor;
- soporte concentrado en una contraparte;
- una experiencia ya diseñada.
Qué suele ceder
- control sobre arquitectura;
- libertad para congelar versiones;
- personalización profunda;
- control directo sobre ciertas dependencias;
- capacidad de decidir cuándo actualizar cada componente.
La relación no es necesariamente negativa. Muchas funciones no estratégicas se benefician precisamente de no internalizar toda la operación.
Pregunta de gobernanza
¿Qué depende del proveedor y qué capacidad conserva el cliente para configurar, auditar, exportar o salir?
2. API
Una API permite que un sistema se comunique programáticamente con otro servicio.
Tendrá una página propia más adelante. Aquí nos interesa sólo como modalidad de adquisición de capacidad.
En vez de comprar una aplicación completa, la organización puede consumir un servicio de IA desde una aplicación propia o de un integrador.
flowchart LR
U[Usuario] --> AP[Aplicación propia]
AP --> API[API externa]
API --> M[Modelo o servicio]
M --> API
API --> AP
Ejemplo jurídico
La firma desarrolla internamente una aplicación de revisión contractual.
La aplicación:
- recibe el contrato;
- prepara el contexto;
- envía determinadas partes a una API de modelo;
- recibe la salida;
- la incorpora a una matriz propia;
- aplica controles internos.
La capacidad generativa es externa.
La experiencia y parte de la lógica del sistema son propias.
Qué gana la organización
Mayor control sobre:
- interfaz;
- datos que se envían;
- lógica de negocio;
- fuentes internas;
- integración;
- workflow;
- presentación del resultado.
Qué asume
También debe resolver:
- desarrollo;
- seguridad de la integración;
- autenticación;
- monitoreo;
- manejo de errores;
- consumo y costos variables;
- mantenimiento;
- evaluación;
- continuidad ante cambios de API.
Comprar una API significa comprar una capacidad externa, no una solución operacional completa.
Más control implica más trabajo propio
Una arquitectura basada en API puede ofrecer mayor flexibilidad que un SaaS cerrado.
Pero esa flexibilidad se transforma en obligación operacional: alguien debe construir y mantener lo que el proveedor SaaS habría entregado como parte del producto.
3. Feature embebida
Muchas organizaciones adoptarán IA sin contratar un nuevo producto de IA.
La capacidad aparecerá como una función dentro de software ya existente.
Ejemplos posibles:
procesador de textos
sistema de correo
gestor documental
CRM
plataforma de productividad
herramienta de investigaciónUn día la interfaz incorpora:
[ Resumir con IA ]
[ Redactar respuesta ]
[ Extraer información ]Por qué esta modalidad es distinta
La barrera de adopción es extremadamente baja.
Los usuarios ya tienen:
- cuenta;
- autenticación;
- permisos;
- contrato;
- soporte;
- datos dentro de la plataforma.
La nueva capacidad puede activarse casi sin un proyecto formal de implementación.
Precisamente por eso aparece un riesgo de gobernanza particular: la incorporación silenciosa de una nueva capacidad dentro de una relación tecnológica antigua.
Qué debemos preguntar
¿Qué cambió cuando se incorporó la función?
Puede haber cambiado:
- el flujo de datos;
- la lista de proveedores;
- las finalidades;
- la documentación;
- la configuración por defecto;
- el pricing;
- las políticas de retención;
- las capacidades disponibles para usuarios.
La facilidad técnica de activar una feature no significa que el cambio sea irrelevante desde el punto de vista jurídico u organizacional.
4. Self-hosted
En una arquitectura self-hosted, la organización asume un grado mayor de control sobre la ejecución de uno o más componentes.
Conviene evitar dos equivalencias incorrectas.
Self-hosted no significa necesariamente “servidores físicamente en nuestra oficina”.
Self-hosted tampoco significa “hemos desarrollado nuestro propio modelo”.
Puede existir, por ejemplo, un modelo de terceros cuyos pesos estén disponibles para ser desplegados en infraestructura administrada por la organización o en una nube bajo mayor control de ésta.
Qué puede aumentar
- control de versión;
- aislamiento;
- configuración;
- observabilidad;
- control sobre datos;
- capacidad de personalización;
- independencia respecto de una API específica.
Qué aumenta también
La carga operacional.
Alguien debe gestionar:
infraestructura
seguridad
actualizaciones
capacidad
monitoreo
incidentes
backups
continuidad
optimización
soporteDovgalenko muestra que las decisiones de despliegue cloud y operación modifican materialmente el TCO. La misma lógica se vuelve todavía más importante cuando una organización decide internalizar componentes de IA.
Control potencial ≠ control efectivo
Tener técnicamente más control no significa ejercerlo bien.
Una arquitectura self-hosted sin equipo, procesos, monitoreo o capacidad de seguridad suficiente puede ser más difícil de gobernar que un servicio externo maduro.
Cuándo puede justificarse
Sin convertirlo en regla universal, puede tener mayor sentido cuando existen necesidades fuertes de:
- aislamiento;
- control de versión;
- operación en entornos restringidos;
- personalización;
- residencia o tratamiento de información;
- independencia tecnológica.
Pero toda ventaja debe compararse con el costo de operar la solución.
5. Desarrollo y configuración
Otra modalidad consiste en contratar servicios para construir, adaptar o integrar una solución.
Aquí el objeto contractual cambia.
Ya no compramos solamente “acceso a un servicio”.
Aparecen elementos típicos de proyecto:
SOW
especificaciones
entregables
hitos
aceptación
change requests
propiedad intelectual
soporte
mantenimientoLa pregunta clave cambia
En SaaS preguntamos:
“¿Qué servicio existe y bajo qué condiciones puedo utilizarlo?”
En desarrollo preguntamos:
“¿Qué debe construirse exactamente y cómo sabremos que fue entregado correctamente?”
Reynolds dedica especial atención a las especificaciones funcionales precisamente porque comprar tecnología sin definir adecuadamente requerimientos aumenta la probabilidad de recibir algo distinto de lo que el negocio esperaba.
Tollen trata igualmente las specifications como una pieza central de los contratos tecnológicos y las conecta con servicios profesionales, cambios y aceptación.
El problema especial de especificar IA
En IA las promesas comerciales pueden ser especialmente vagas:
“La solución identificará riesgos contractuales mediante inteligencia artificial.”
Eso no es todavía una especificación suficientemente útil.
Podríamos necesitar aclarar:
- qué documentos soporta;
- qué categorías de riesgo;
- qué tipo de salida;
- qué criterios de completitud;
- qué excepciones;
- qué desempeño mínimo;
- qué se considera error material;
- cómo se prueba aceptación.
La dificultad no se resuelve exigiendo “100 % de precisión”.
Se resuelve convirtiendo la necesidad del negocio en criterios verificables y apropiados al riesgo.
6. Híbrido
En la práctica, muchas arquitecturas relevantes serán híbridas.
La organización compra algunos componentes, controla otros y combina servicios externos con datos o procesos propios.
Ejemplo:
flowchart LR
U[Usuario] --> A[Aplicación interna]
A --> D[Datos internos]
A --> R[Reglas propias]
A --> M[Modelo externo]
A --> C[Controles corporativos]
Otra organización podría utilizar:
SaaS jurídico
+
repositorio interno
+
workflow propio de aprobación
+
registro corporativoPor qué el híbrido es frecuente
Porque permite separar aquello que conviene estandarizar de aquello que conviene conservar bajo control.
Por ejemplo:
- usar un modelo externo para una capacidad genérica;
- mantener internamente criterios de riesgo;
- conservar datos sensibles en una capa controlada;
- integrar el resultado con sistemas institucionales propios.
El costo de combinar
El híbrido no entrega automáticamente “lo mejor de ambos mundos”.
También puede aumentar:
- complejidad de integración;
- número de dependencias;
- puntos de fallo;
- necesidades de monitoreo;
- carga de gobernanza.
La arquitectura combinada exige coordinación.
Build · Buy · Combine
Las modalidades anteriores pueden reunirse en una pregunta estratégica más general.
Buy — comprar
La organización adquiere una solución existente.
Puede ser apropiado cuando:
- la necesidad es estándar;
- existe una oferta madura;
- la rapidez importa;
- la función no constituye una diferenciación estratégica;
- la organización no quiere operar internamente la tecnología.
Ventajas típicas
rapidez
menor esfuerzo inicial
operación delegada
soporte concentradoRiesgos típicos
menor control
lock-in
cambios del proveedor
dependencias externasBuild — construir
La organización desarrolla una solución propia o asume control significativo sobre su arquitectura.
Puede justificarse cuando:
- los requerimientos son realmente particulares;
- la integración profunda es esencial;
- la tarea o el dato constituyen una ventaja estratégica;
- existen requisitos fuertes de control;
- la organización tiene madurez técnica suficiente.
Ventajas típicas
control
personalización
integración
propiedad de ciertas capasRiesgos típicos
costo
plazo
mantenimiento
seguridad
operación
riesgo de proyectoDovgalenko señala una intuición clásica del debate build-or-buy: no conviene construir aquello que ya existe de forma adecuada en el mercado salvo que exista una justificación real vinculada a requerimientos únicos o ventaja competitiva. La formulación exacta dependerá de cada organización, pero el principio es valioso: construir debe resolver un problema, no satisfacer una preferencia abstracta por control.
Combine — combinar
La organización compra componentes estándar y construye o controla aquello que considera diferencial.
Ejemplo:
modelo externo
+
aplicación propia
+
datos propios
+
workflow propio
+
controles internosPuede ser la estrategia más flexible, pero también exige capacidad de integración y gobernanza.
La decisión no es ideológica
Un error frecuente consiste en convertir build/buy en una discusión moral:
“Lo local siempre es más seguro.”
“El SaaS siempre es más eficiente.”
“Construir siempre entrega más control.”
“Comprar siempre es más barato.”
Ninguna de esas frases es universalmente correcta.
La decisión depende de variables concretas.
| Dimensión | Pregunta |
|---|---|
| Criticidad | ¿Qué ocurre si el sistema falla? |
| Sensibilidad | ¿Qué información procesa? |
| Diferenciación | ¿Esta capacidad es estratégica o estándar? |
| Control | ¿Qué necesitamos poder configurar o congelar? |
| Madurez interna | ¿Tenemos equipo para operar lo que internalizamos? |
| Integración | ¿Con qué sistemas debe conectarse? |
| Volumen | ¿Cómo cambia el costo al aumentar el uso? |
| Reversibilidad | ¿Qué tan difícil sería sustituir la solución? |
| Tiempo | ¿Cuánto podemos esperar para implementar? |
La respuesta puede ser diferente para dos tareas dentro de la misma organización.
Ejemplo
Una firma puede decidir:
resúmenes de baja sensibilidad
→ servicio externo
revisión de documentos confidenciales
→ entorno más controlado
workflow de aprobación
→ sistema internoEso no es inconsistencia.
Es asignación diferenciada de control según riesgo.
Precio no es costo
Una de las distinciones más importantes de procurement es separar precio y costo total.
Una suscripción puede anunciar:
USD 30 por usuario / mesEse número es un precio.
No necesariamente representa todo lo que costará incorporar la solución a la organización.
El Total Cost of Ownership o TCO intenta observar un universo mayor.
Dependiendo de la modalidad puede incluir:
- licencias;
- consumo de API;
- implementación;
- integración;
- migración;
- infraestructura;
- personal interno;
- capacitación;
- soporte;
- seguridad;
- monitoreo;
- entornos de prueba;
- mantenimiento;
- cambios;
- salida y transición.
Dovgalenko muestra, por ejemplo, que la elección de arquitectura cloud modifica componentes importantes del TCO: localización, redundancia, disaster recovery y ambientes de prueba pueden producir costos que no aparecen en una tarifa superficial.
Reynolds igualmente trata el TCO como parte de la forma real de la solución.
Un ejemplo ficticio
Opción A — SaaS
suscripción 30
implementación 4
integración 3
operación interna 3
--------------------
base comparativa 40Opción B — API + desarrollo
consumo API 8
desarrollo 18
infraestructura 5
operación interna 10
--------------------
base comparativa 41Los números son deliberadamente ficticios.
Lo importante es la lógica: comparar 30 contra 8 sería comparar precios de componentes distintos, no costo de soluciones equivalentes.
Costo tampoco es valor
Incluso el TCO no responde la última pregunta.
Una solución puede ser barata y no resolver el problema.
Otra puede ser cara y generar beneficios superiores.
Por eso el material del curso propone un cambio de foco:
¿Puede hacer algo interesante?hacia:
¿Sirve para este proceso,
bajo estas restricciones,
con estos costos
y con estos controles?Ésta es una pregunta de valor situado.
La organización no compra inteligencia abstracta.
Compra capacidad para producir determinado trabajo dentro de determinadas restricciones.
Comprar también es gobernar el cambio
La adquisición no termina el día de la firma.
Los sistemas de IA pueden cambiar rápidamente.
Puede cambiar:
- el modelo;
- la versión;
- la interfaz;
- el precio;
- las dependencias;
- las políticas;
- las capacidades;
- el tratamiento de datos;
- las métricas de desempeño.
Por eso una estrategia de adquisición debe preguntarse desde el comienzo:
¿Qué puede cambiar?
¿Quién controla el cambio?
¿Qué debe notificarse?
¿Qué exige nueva evaluación?
¿Qué cambio material permite terminar o migrar?
Esta es la conexión entre comprar y gobernar.
No basta seleccionar una arquitectura adecuada en el día uno.
Debemos poder mantenerla dentro de parámetros aceptables durante la relación.
Caso conductor: tres arquitecturas para el mismo problema
La firma quiere reducir el tiempo de primera revisión de contratos de proveedores de IA.
Estrategia A — SaaS jurídico
La firma contrata una plataforma terminada.
Ventaja: rapidez.
Control principal: configuración, contrato, permisos y procedimiento interno.
Dependencia principal: proveedor de la aplicación y sus subproveedores.
Pregunta clave: ¿qué funcionalidad promete y qué puede cambiar unilateralmente?
Estrategia B — API + aplicación propia
La firma construye una aplicación interna que consume un modelo externo.
Ventaja: mayor control sobre proceso, interfaz y fuentes.
Carga adicional: desarrollo, seguridad, evaluación y mantenimiento.
Dependencia principal: proveedor del modelo y capacidad interna de ingeniería.
Pregunta clave: ¿tenemos capacidad para operar lo que estamos internalizando?
Estrategia C — híbrida
La firma utiliza capacidad externa para generación, mantiene internamente criterios de riesgo y ejecuta aprobación dentro de sus propios sistemas.
Ventaja: control selectivo sobre capas sensibles.
Carga adicional: integración y coordinación.
Pregunta clave: ¿la arquitectura distribuye correctamente el control según criticidad?
Ninguna estrategia es correcta por definición.
La elección depende de la tarea.
Una matriz inicial de decisión
Antes de elegir modalidad, conviene poder completar algo parecido a esto:
| Pregunta | Respuesta esperada |
|---|---|
| ¿Qué problema queremos resolver? | tarea operacional concreta |
| ¿Qué información necesita? | fuentes y sensibilidad |
| ¿Qué errores son materialmente inaceptables? | límites de riesgo |
| ¿Qué nivel de control necesitamos? | versión, datos, permisos, proceso |
| ¿Qué capacidad interna tenemos? | desarrollo, seguridad, operación |
| ¿Qué volumen esperamos? | usuarios, documentos, llamadas |
| ¿Qué dependencias existirán? | modelo, cloud, datos, terceros |
| ¿Cómo probaremos que funciona? | criterios de evaluación |
| ¿Qué debe quedar registrado? | evidencia y trazabilidad |
| ¿Cómo podremos salir? | portabilidad, exportación, transición |
La matriz no produce automáticamente una respuesta.
Produce algo más importante: una decisión que puede justificarse.
Qué debemos retener
SaaS, API, feature embebida, self-hosted, desarrollo y arquitecturas híbridas son formas distintas de distribuir capacidad y responsabilidad operacional.
La decisión build · buy · combine debe considerar:
- tarea;
- riesgo;
- datos;
- control;
- costo;
- madurez interna;
- integración;
- reversibilidad.
El criterio no es maximizar control ni minimizar precio.
Es construir una arquitectura proporcional al problema.
La idea que cierra esta primera macrosección es:
No contratamos “inteligencia artificial” como un objeto simple. Contratamos o construimos una combinación de software, modelos, datos, infraestructura, interfaces, documentación, cambios, soporte y controles.
Comprender esa combinación es el primer requisito para poder gobernarla.
Dónde estamos en el recorrido
Hasta ahora hemos estado entendiendo el sistema.
Ya podemos preguntar:
¿Qué objeto estoy utilizando?
¿Qué capas lo componen?
¿Quién sostiene esas capas?
¿Qué modalidad de adquisición distribuye mejor el control y el riesgo?
Pero todavía no hemos estudiado cómo especificar correctamente una tarea al modelo.
Ése es el siguiente cambio de verbo del handbook.
Pasamos de:
ENTENDERa:
INSTRUIRLa próxima macrosección comienza con el objeto más sencillo de esa nueva etapa:
el prompt.