flowchart LR
D[Documento] --> A[Aplicación]
A --> M[Modelo]
M --> R[Resultado]
La IA como sistema sociotécnico
Por qué el comportamiento real de una solución de IA depende conjuntamente de modelos, datos, infraestructura, interfaces, personas, procedimientos y controles.
La IA como sistema sociotécnico
En la página anterior distinguimos tres niveles: modelo, sistema y aplicación. Esa separación evita tratar una capacidad computacional como si fuera equivalente al producto completo.
Pero todavía podríamos conservar una imagen incompleta.
Podríamos pensar que, una vez que dejamos de mirar solamente el modelo y comenzamos a mirar el sistema, el problema queda resuelto describiendo más software: bases de datos, servidores, integraciones, interfaces y reglas.
En el trabajo profesional eso sigue siendo insuficiente.
Una herramienta no determina por sí sola cuándo debe utilizarse. Alguien define qué documentos puede recibir. Alguien decide quién puede acceder. Una política establece qué información puede cargarse. Un procedimiento determina cuándo una recomendación requiere revisión. Un abogado interpreta el resultado. Un administrador configura permisos. Una organización decide qué errores son aceptables y cuáles obligan a detener el proceso.
El comportamiento que finalmente observamos surge de la interacción entre todos esos elementos.
Por eso necesitamos una perspectiva distinta:
una solución de IA utilizada en una organización debe entenderse como parte de un sistema sociotécnico.
Idea central
Para este handbook, mirar la IA como sistema sociotécnico significa analizar conjuntamente:
modelo + datos + infraestructura + interfaz + personas + procedimientos + controles.
No basta preguntar si cada elemento “funciona” aisladamente. Hay que observar cómo se relacionan y qué resultados produce esa relación en la práctica.
Qué significa realmente “sociotécnico”
La palabra puede sonar más complicada de lo que es.
No significa simplemente:
“la tecnología importa, pero las personas también”.
Significa que muchas propiedades relevantes del sistema no pertenecen exclusivamente a la tecnología ni exclusivamente a las personas, sino a la forma en que ambas están organizadas.
Pensemos en una herramienta que asigna a cada contrato una categoría:
BAJO
MEDIO
ALTO¿Dónde está “el riesgo alto”?
No existe necesariamente como una propiedad natural escrita dentro del contrato. Para producir esa clasificación intervienen varias decisiones:
- qué cláusulas se consideran relevantes;
- qué criterio define “alto”;
- qué documentos adicionales se consultan;
- qué modelo procesa la información;
- cómo se configura el sistema;
- qué resultado ve el usuario;
- qué hace la organización después.
La clasificación final es un producto sociotécnico.
El sistema no termina donde termina el software
Una representación puramente técnica podría mostrar:
Pero en una operación profesional real podría ser más apropiado observar:
flowchart LR
U[Usuario] --> UI[Interfaz]
UI --> D[Datos y documentos]
D --> M[Modelo]
M --> O[Resultado]
O --> H[Revisión humana]
H --> P[Procedimiento]
P --> X[Decisión]
C[Controles] -. condicionan .-> UI
C -. condicionan .-> H
C -. condicionan .-> P
I[Infraestructura] -. sostiene .-> UI
I -. sostiene .-> D
I -. sostiene .-> M
El segundo diagrama no es “más correcto” porque tenga más cajas. Es más útil porque hace visibles relaciones que pueden ser decisivas para comprender el resultado.
Modelo
El modelo sigue siendo una pieza central.
Puede aportar capacidades como:
- generación de texto;
- clasificación;
- extracción;
- comparación;
- transformación;
- producción de recomendaciones o evaluaciones preliminares.
Pero desde una mirada sociotécnica el interés principal ya no es solamente:
“¿qué tan capaz es el modelo?”
También preguntamos:
“¿qué papel se le asignó dentro del proceso?”
Un mismo modelo puede funcionar como:
- asistente de redacción;
- clasificador preliminar;
- mecanismo de extracción;
- evaluador de documentos;
- componente de una aplicación mayor.
La importancia del modelo depende de qué decisiones posteriores se apoyan en su salida.
Una clasificación automática que solamente organiza documentos para revisión humana tiene un impacto distinto de una clasificación que determina automáticamente si un contrato continúa o se rechaza.
La capacidad técnica puede ser idéntica. La función institucional no lo es.
Datos
La palabra datos incluye varios fenómenos diferentes y conviene distinguirlos desde el comienzo.
En un sistema de IA pueden existir, entre otros:
- datos utilizados durante el desarrollo o entrenamiento del modelo;
- información que el usuario entrega durante una ejecución;
- documentos o bases que el sistema recupera durante la tarea;
- datos de configuración;
- metadatos y logs generados por la operación;
- resultados producidos por el propio sistema.
No todos tienen el mismo origen, finalidad ni régimen de acceso.
La calidad del resultado depende del universo informacional
Supongamos que queremos determinar si un contrato de proveedor permite utilizar datos del cliente para desarrollar o mejorar productos del proveedor.
El acuerdo principal parece prohibir ese uso.
Sin embargo, un anexo denominado AI Product Terms contiene una excepción amplia.
Si el sistema procesa solamente el contrato principal, puede producir una respuesta internamente razonable y jurídicamente incompleta.
El problema no necesita encontrarse en el modelo.
Puede encontrarse en la selección del universo documental.
Esta observación es especialmente importante para el trabajo jurídico porque la información relevante suele estar distribuida entre:
- contrato principal;
- anexos;
- políticas incorporadas por referencia;
- legislación;
- jurisprudencia;
- documentos internos;
- comunicaciones del negocio.
Una conclusión sólo puede evaluarse respecto de la información que el sistema tuvo realmente disponible.
“La organización tiene el documento” no significa “el sistema utilizó el documento”
Antes de atribuir una omisión al modelo, pregunte si la información pertinente fue efectivamente incorporada al proceso.
Infraestructura
Todo sistema necesita un entorno material de ejecución.
La infraestructura puede incluir:
cómputo
almacenamiento
redes
servicios cloud
entornos de ejecución
mecanismos de respaldo
seguridad de infraestructuraPara un usuario que interactúa con una interfaz web, estas capas pueden ser invisibles.
Para la operación profesional pueden ser decisivas.
La infraestructura puede afectar:
- disponibilidad;
- latencia;
- continuidad;
- localización de datos;
- recuperación frente a fallos;
- aislamiento entre clientes;
- costos;
- capacidad de escalar.
Desde la perspectiva jurídica y de procurement, esto significa que una función aparentemente sencilla —“subir un contrato y obtener una revisión”— puede descansar sobre decisiones de hosting, almacenamiento y continuidad que merecen análisis propio.
No necesitamos que el abogado aprenda administración de servidores.
Sí necesitamos que pueda preguntar:
¿Dónde corre realmente el servicio?
¿Dónde quedan los documentos?
¿Qué ocurre si falla la infraestructura principal?
¿Quién controla la recuperación?
Interfaz
La interfaz suele tratarse como una cuestión de experiencia de usuario. En un sistema sociotécnico cumple una función mucho más profunda.
La interfaz determina qué puede ver y hacer una persona.
Puede definir:
- qué archivos pueden cargarse;
- qué opciones se ofrecen;
- qué información se oculta;
- qué advertencias aparecen;
- qué fuentes pueden inspeccionarse;
- qué acciones están disponibles;
- cómo se distingue texto original de contenido generado;
- qué nivel de confianza transmite el sistema.
La interfaz también distribuye confianza
Comparemos dos diseños.
Diseño A
RIESGO: ALTO
Recomendación:
No aprobar.Diseño B
RIESGO: ALTO
Texto contractual:
“El proveedor podrá utilizar Customer Content para mejorar sus servicios...”
Criterio aplicado:
Política interna de contratación, sección 4.2.
Inferencia:
La cláusula autoriza una finalidad más amplia que la aceptada internamente.
Información faltante:
No se encontró el DPA.
Acción sugerida:
Escalar a privacidad.El segundo diseño no hace automáticamente correcta la clasificación.
Pero facilita una revisión profesional porque hace visibles texto, criterio, inferencia e información faltante.
La interfaz puede entonces contribuir a la verificabilidad y contestabilidad del sistema.
Personas
Las personas forman parte del sistema, no porque “corrijan mágicamente” cualquier problema de IA, sino porque cumplen funciones concretas.
Puede haber personas que:
- definan la finalidad;
- seleccionen el proveedor;
- configuren el sistema;
- preparen datos;
- utilicen la aplicación;
- revisen resultados;
- aprueben excepciones;
- mantengan políticas;
- respondan ante incidentes.
La expresión “human-in-the-loop” puede ocultar diferencias importantes. No basta afirmar que “siempre hay un humano”.
Tenemos que preguntar:
¿Qué persona?
¿En qué momento?
¿Con qué información?
¿Con qué autoridad?
¿Puede rechazar el resultado?
¿Tiene tiempo y conocimientos para revisarlo?
¿Queda registrada su intervención?
Presencia humana no equivale a supervisión efectiva
Supongamos que un sistema procesa 1.000 contratos y entrega a un abogado cinco segundos para confirmar cada resultado.
Formalmente existe revisión humana.
Sustantivamente puede ser una revisión ilusoria.
Del mismo modo, si la interfaz no muestra las fuentes utilizadas, el revisor puede carecer de información para evaluar la conclusión.
Por eso una arquitectura sociotécnica debe examinar la capacidad real de la persona para intervenir, no solamente su presencia nominal.
Procedimientos
Un procedimiento determina qué ocurre antes y después de cada uso de la tecnología.
Podemos tener exactamente el mismo modelo y la misma aplicación en dos organizaciones y obtener sistemas institucionales diferentes.
Organización A
flowchart LR
A[Contrato] --> B[Revisión IA]
B --> C{Riesgo alto?}
C -- Sí --> D[Abogado senior]
D --> E[Privacidad / Seguridad]
E --> F[Aprobación]
C -- No --> F
Organización B
flowchart LR
A[Contrato] --> B[Revisión IA]
B --> C[Usuario ve resultado]
C --> D[Continúa según criterio personal]
La tecnología puede ser idéntica.
La gobernanza operacional no lo es.
Los procedimientos pueden establecer:
- quién inicia una tarea;
- qué información es obligatoria;
- qué criterios se aplican;
- qué excepciones existen;
- qué requiere aprobación;
- cuándo debe detenerse el proceso;
- quién registra el cierre.
Más adelante estudiaremos workflows y playbooks como abstracciones específicas para organizar trabajo. Aquí sólo necesitamos entender que el procedimiento humano y organizacional ya forma parte del sistema que produce el resultado.
Controles
Los controles establecen límites, verificaciones y mecanismos de supervisión.
Pueden adoptar formas distintas:
Controles preventivos
Intentan impedir que ocurra una acción no permitida.
Ejemplos:
- bloquear determinados tipos de archivo;
- restringir acceso por rol;
- impedir escritura en un sistema crítico;
- exigir aprobación antes de enviar información externa.
Controles detectivos
Permiten descubrir que algo ocurrió o que existe una desviación.
Ejemplos:
- logs;
- alertas;
- monitoreo;
- revisión de excepciones.
Controles correctivos
Permiten responder al problema.
Ejemplos:
- reversión;
- deshabilitación;
- corrección de configuraciones;
- escalamiento;
- actualización de criterios.
La clasificación no pretende agotar la teoría de controles. Sirve para mostrar que “poner una instrucción en el prompt” es solamente una forma posible de orientar comportamiento y no siempre constituye el control adecuado.
Instrucción no es lo mismo que control
“NO envíes información confidencial” puede ser una instrucción.
“Esta cuenta no tiene permiso técnico para enviar archivos fuera del dominio” es un control de otra naturaleza.
Cuando una acción tiene consecuencias relevantes, confiar exclusivamente en lenguaje puede ser insuficiente.
Cómo interactúan las siete piezas
La utilidad de la perspectiva sociotécnica aparece cuando dejamos de analizar cada componente como una lista y comenzamos a observar relaciones.
Tomemos el caso conductor.
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
El sistema de revisión podría operar así:
flowchart TB
P[Persona carga contrato]
P --> UI[Interfaz]
UI --> D[Contrato + anexos + criterios]
D --> M[Modelo]
M --> R[Hallazgos]
R --> UI
UI --> H[Revisor humano]
H --> PR[Procedimiento de aprobación]
PR --> DEC[Decisión]
C[Controles] -. permisos .-> UI
C -. escalamiento .-> PR
C -. logging .-> DEC
I[Infraestructura] -. soporta .-> D
I -. soporta .-> M
Ahora supongamos que la decisión resulta equivocada.
Una investigación causal debería poder preguntar:
- ¿se cargó el documento correcto?;
- ¿el anexo fue procesado?;
- ¿los criterios estaban actualizados?;
- ¿el modelo clasificó mal?;
- ¿la interfaz mostró la advertencia?;
- ¿el procedimiento exigía escalamiento?;
- ¿el revisor podía detener la operación?;
- ¿los controles funcionaron?;
- ¿existen registros suficientes para saberlo?
Decir simplemente “la IA se equivocó” elimina precisamente la información necesaria para corregir el sistema.
Del error individual al fallo sistémico
Un beneficio importante de esta perspectiva es que permite distinguir error de componente y fallo de sistema.
Un modelo puede cometer un error aislado que el procedimiento detecta y corrige.
En ese caso, el componente falló, pero el sistema puede haber funcionado según diseño.
Por el contrario, un modelo puede producir una respuesta dudosa y el sistema puede presentarla como definitiva, no exigir evidencia y permitir una acción irreversible.
Aquí el problema no es sólo la respuesta incorrecta. Es la arquitectura que permitió que esa respuesta se transformara en una consecuencia sin controles suficientes.
Esta distinción cambia la pregunta de gobernanza:
no necesitamos diseñar un mundo en que ningún componente falle;
necesitamos diseñar sistemas capaces de detectar, contener y corregir fallos compatibles con el riesgo de la tarea.
Capacidad, permiso, decisión y responsabilidad
La mirada sociotécnica ayuda a mantener una distinción transversal que será fundamental cuando lleguemos a herramientas y agentes.
CAPACIDAD TÉCNICA
¿Qué puede hacer el sistema?
PERMISO
¿Qué está autorizado a hacer?
DECISIÓN
¿Qué puede seleccionar dentro de las opciones permitidas?
RESPONSABILIDAD
¿Quién responde por el resultado y por la configuración de esas capacidades?Pensemos en una aplicación que puede crear un ticket en el sistema de gestión de incidentes.
Capacidad: técnicamente puede hacerlo.
Permiso: la cuenta puede tener o no autorización de escritura.
Decisión: el sistema puede estar diseñado para proponer la creación o para ejecutarla automáticamente.
Responsabilidad: la organización debe haber definido quién controla ese diseño y quién responde por su uso.
La cadena evita un error frecuente: suponer que una capacidad técnicamente disponible debe convertirse automáticamente en autoridad operacional.
La perspectiva sociotécnica mejora el análisis jurídico
Confidencialidad
La pregunta no es solamente:
¿entrena el modelo con nuestros datos?
También puede ser necesario entender:
- qué aplicación recibe la información;
- qué personas tienen acceso;
- qué logs se generan;
- qué servicios externos intervienen;
- dónde se almacena;
- qué procedimiento autoriza su uso.
Protección de datos
La arquitectura técnica permite identificar actores, flujos y finalidades, pero la calificación jurídica depende del tratamiento concreto.
No toda dependencia técnica es automáticamente un subprocesador.
No todo dato utilizado por el sistema tiene el mismo rol.
Responsabilidad
Si un resultado causa daño, necesitamos reconstruir si el problema provino de:
- modelo;
- dato;
- configuración;
- integración;
- interfaz;
- procedimiento;
- uso humano;
- falta de control.
La precisión causal es condición para asignar obligaciones de manera razonable.
Evidencia y auditabilidad
Una organización puede necesitar demostrar no solamente cuál fue el resultado final, sino también:
- qué documento se procesó;
- qué criterio se aplicó;
- qué versión estaba activa;
- qué aprobación ocurrió;
- qué excepción se autorizó.
La capacidad de reconstrucción depende de decisiones sociotécnicas sobre logging, documentación y proceso.
Evitar dos reduccionismos
La perspectiva sociotécnica busca evitar dos extremos.
Reduccionismo tecnológico
“El modelo es bueno, por tanto el sistema es bueno.”
No necesariamente.
Reduccionismo humano
“Hay una persona revisando, por tanto el sistema es seguro.”
Tampoco necesariamente.
La pregunta correcta es relacional:
¿Cómo están distribuidas las funciones entre tecnología, personas y reglas organizacionales y qué ocurre cuando una de ellas falla?
Una plantilla mental para analizar un sistema
Ante una solución profesional de IA, podemos utilizar siete preguntas iniciales:
| Dimensión | Pregunta |
|---|---|
| Modelo | ¿Qué capacidad aporta? |
| Datos | ¿Con qué información trabaja? |
| Infraestructura | ¿Dónde y sobre qué servicios opera? |
| Interfaz | ¿Qué ve y puede hacer el usuario? |
| Personas | ¿Quién configura, usa, revisa y decide? |
| Procedimientos | ¿Qué secuencia institucional rodea la tarea? |
| Controles | ¿Qué impide, detecta o corrige desviaciones? |
No es todavía una auditoría completa.
Es una defensa contra la simplificación.
Qué debemos retener
La IA en una organización no es solamente un artefacto técnico que produce outputs.
Es una capacidad inserta en un entorno de datos, infraestructura, interfaces, personas, procedimientos y controles.
El resultado final depende de cómo se articula el conjunto.
Esto explica por qué:
- el mismo modelo puede producir resultados institucionales muy distintos;
- una interfaz puede aumentar o disminuir verificabilidad;
- un procedimiento puede contener errores o amplificarlos;
- la presencia humana no garantiza supervisión efectiva;
- un control técnico puede ser más fuerte que una instrucción lingüística;
- para investigar un incidente debemos reconstruir relaciones causales, no buscar una única “culpa de la IA”.
El problema que todavía queda abierto
La perspectiva sociotécnica amplía correctamente nuestro campo de visión.
Pero ahora tenemos muchas piezas al mismo tiempo.
Necesitamos una forma de ordenar la arquitectura técnica sin perder de vista el conjunto.
La siguiente página introduce una representación por capas que utilizaremos como mapa:
el AI Stack.