Responsables, usuarios, datos, proveedores y dependencias
El inventario cobra utilidad cuando permite reconocer qué sostiene cada uso de IA y quién puede actuar si algo cambia.
Recupera las fichas de la lección 4.3 y la matriz de responsabilidades del módulo 3. Tiempo orientativo: 15 minutos de lectura y 25 de práctica.
La lección de un vistazo
Una ficha aislada no explica el servicio
Conocer el nombre de un chatbot no permite saber quién mantiene sus fuentes, quién responde ante una consulta incorrecta o qué ocurre si falla la derivación a una persona. Esas relaciones también necesitan hacerse visibles.
Una dependencia es algo que el uso necesita para funcionar en las condiciones previstas. Puede ser técnica, informativa, humana u organizativa. En esta lección construiremos un mapa práctico de relaciones; no sustituye un análisis completo de arquitectura, riesgos o continuidad.
Describe qué aporta cada dependencia. Una lista de nombres sin explicar la relación sigue dejando el trabajo de interpretación a quien tenga que intervenir.
Distinguir responsabilidades que suelen mezclarse
| Función propuesta | Qué conviene aclarar |
|---|---|
| Responsable del uso | Quién responde por la actividad y sus condiciones en el proceso de negocio o servicio. |
| Responsable técnico del sistema | Quién mantiene o coordina configuración, integraciones y soporte, dentro de su autoridad. |
| Responsable de la fuente de información | Quién valida y mantiene el contenido que el sistema utiliza. |
| Persona que supervisa | Quién revisa una salida o interviene, en qué momento y con qué medios y límites. |
| Responsable de la relación con el proveedor | Quién tramita consultas, cambios y escalados externos y sigue su respuesta. |
| Responsable del registro | Quién mantiene la ficha y coordina la comprobación de los datos. |
Estos nombres son propuestas didácticas, no puestos obligatorios. Una misma persona puede asumir varias funciones, siempre que queden claros sus límites y las posibles necesidades de revisión adicional.
No deduzcas que quien administra una herramienta puede aprobar cualquier finalidad ni que quien actualiza el inventario responde por todas las decisiones del servicio. Vincula las funciones a la matriz del módulo 3 y confirma las asignaciones.
Registra suplencias o vías alternativas cuando sean necesarias. Es preferible referenciar un directorio mantenido y accesible que copiar teléfonos que quedarán desactualizados en muchas fichas.
Usuarios, destinatarios y personas afectadas
Quien maneja la herramienta no siempre coincide con quien recibe su resultado ni con quien experimenta sus consecuencias.
En el caso del clasificador de TechServe IT, un técnico puede consultar la prioridad propuesta. La persona que abrió la incidencia puede verse afectada por cómo se utilice esa prioridad, aunque nunca interactúe con la IA. En el copiloto, un técnico puede preparar una respuesta que después recibe un cliente.
Registra categorías de personas y su relación con el uso: operadores, revisores, destinatarios y otros afectados. No hace falta incluir nombres personales si la función o el grupo identifica suficientemente la relación.
Comprueba quién puede corregir un resultado y por qué vía se comunica una discrepancia. Si no está claro, déjalo como una cuestión pendiente. No supongas que existe un canal de revisión porque el sistema tenga una persona responsable asignada.
Seguir los datos y las salidas
Para cada uso, describe de dónde llega la información, qué categorías se procesan y adónde van los resultados. Distingue los flujos confirmados de los que todavía estás investigando.
| Relación | Pregunta de inventario |
|---|---|
| Fuente → sistema | ¿Qué información recibe, de dónde procede y quién mantiene esa fuente? |
| Sistema → destinatario | ¿Qué salida produce, quién la recibe y cómo se utiliza? |
| Sistema → otro servicio | ¿Qué se transmite o ejecuta mediante una integración y con qué condiciones? |
| Actividad → registro | ¿Dónde queda constancia, quién puede consultarla y qué documentación describe su tratamiento? |
No confundas los datos introducidos durante el uso con los datos utilizados para entrenar un modelo. Que una herramienta procese un ticket no demuestra que ese ticket se utilice para entrenamiento. Si necesitas conocer ese tratamiento, consulta las condiciones y la configuración aplicables y anota sus límites.
Una base de conocimiento tampoco es necesariamente una fuente de entrenamiento. Puede consultarse durante la generación de una respuesta o intervenir de otra manera. Registra el mecanismo confirmado, evitando atribuir una arquitectura que nadie ha comprobado.
El inventario debe orientar hacia la documentación pertinente, sin convertirse en un depósito de datos sensibles. Describe categorías y referencias; no copies credenciales, conversaciones completas ni información personal innecesaria.
Describir la aportación del proveedor
«Proveedor de IA» puede referirse a una plataforma, un modelo, una integración, un servicio de alojamiento o el soporte de una aplicación. Identifica qué aporta realmente cada parte y quién mantiene la relación.
Si existe una cadena de proveedores, registra las dependencias relevantes que puedas confirmar. Lo desconocido debe quedar como tal, con una consulta o acción asignada. No completes la cadena por intuición.
- Servicio o componente suministrado y referencia contractual o documental.
- Punto de contacto y vía de escalado acordada.
- Información disponible sobre cambios, versiones y avisos de incidencias.
- Condiciones y limitaciones relevantes para el uso, con fuente y fecha.
- Aspectos que la organización puede configurar y aspectos que dependen del tercero.
La existencia de un contrato o de un soporte externo no demuestra que haya una respuesta inmediata ni resuelve por sí sola la continuidad del servicio. No inventes tiempos de atención o recuperación: identifica los compromisos comprobados y las lagunas.
Un proveedor puede mantener un componente; la organización necesita seguir decidiendo cómo se utiliza ese componente en su servicio. La distribución concreta de obligaciones requiere revisar los acuerdos y responsabilidades aplicables, no deducirla del nombre de la herramienta.
Reconocer dependencias compartidas y alternativas
Varios usos pueden depender de la misma fuente, conexión o equipo de supervisión. Ver esa relación ayuda a localizar qué fichas deben revisarse ante un cambio. Dos proveedores distintos tampoco garantizan independencia si ambos utilizan un componente común.
Para cada dependencia relevante, anota qué función sostiene, qué consecuencia podría tener su indisponibilidad y qué alternativa está prevista. Distingue una alternativa propuesta de una preparada y comprobada.
«Pasamos a atención manual» no explica si hay personas disponibles, si pueden acceder a la información ni si el canal manual depende de la misma plataforma que acaba de fallar. Son condiciones que necesitan confirmación.
Una dependencia compartida no constituye automáticamente un riesgo inaceptable. Su importancia debe evaluarse según el contexto y las consecuencias. Aquí hacemos visible la relación para permitir esa evaluación posterior.
TechServe IT: el chatbot responde, pero el servicio falla
Ampliación hipotética del caso. Supongamos que el chatbot consulta una base de conocimiento y dispone de una derivación a agentes humanos. Tras un cambio, algunas respuestas utilizan instrucciones antiguas. Al intentar derivar una conversación, el operador encuentra que la cola de atención no está disponible.
El proveedor del modelo indica que su servicio está operativo. El inventario solo recoge «chatbot, proveedor externo, responsable: TI».
La disponibilidad del modelo no confirma que el servicio completo funcione. Tampoco demuestra que sea ajeno a las incidencias. Antes de atribuir causas, necesitamos localizar las relaciones y contrastar lo ocurrido.
| Dependencia hipotética | Qué investigar | Función a consultar o confirmar |
|---|---|---|
| Base de conocimiento | Qué contenido estaba vigente y qué información se consultó realmente. | Responsable de contenido y administración de la integración. |
| Conexión con la fuente | Si el cambio llegó al entorno usado y si hubo fallos de acceso o actualización. | Responsable técnico del sistema. |
| Modelo externo | Qué servicio intervino y qué evidencia permite acotar su comportamiento. | Responsable de la relación con el proveedor. |
| Cola de atención humana | Disponibilidad del canal, asignaciones y cobertura real. | Responsable de operaciones y soporte de la plataforma. |
| Alternativa de atención | Si existe una vía autorizada, disponible y utilizable por el equipo. | Responsable del uso y autoridad de decisión correspondiente. |
Las funciones de la tabla son propuestas para el ejercicio, no asignaciones ya confirmadas. Tampoco sabemos aún si las respuestas antiguas se deben a la fuente, a la integración, a una configuración o a otra causa.
En la actuación real, aplica el circuito de incidencias y las medidas autorizadas según corresponda. Completar el inventario ayuda a comprender el servicio, pero no debe retrasar una respuesta necesaria.
Cómo quedaría una relación útil en la ficha
Uso: atender consultas de primer nivel. Dependencia propuesta en este escenario: cola de atención humana para los casos que requieren derivación. Consecuencia a contrastar: imposibilidad de completar esa derivación. Responsable: pendiente de confirmar con operaciones. Alternativa: pendiente de localizar y comprobar. Evidencia: registro de la prueba o incidencia, con fecha y entorno.
Esta anotación explica el vínculo y sus lagunas sin dar por disponible una alternativa que todavía no se ha comprobado.
Tu actividad: ficha de relaciones y dependencias
Elige un uso de la lección 4.3. Describe una relación con personas, una con información y una con un servicio o proveedor, siempre que sean pertinentes. Si no las conoces, formula la comprobación necesaria. Para cada relación, aclara qué aporta y qué cambiaría si no estuviera disponible.
Criterios para revisar la ficha
- Cada relación explica qué aporta al uso, no solo el nombre del recurso.
- Se distinguen responsabilidad operativa, técnica y de mantenimiento del registro.
- Los usuarios no se confunden con todas las personas afectadas.
- Los flujos de datos no se presentan como entrenamiento sin evidencia.
- La alternativa declara su estado y las condiciones necesarias.
- Las lagunas y causas hipotéticas se diferencian de los hechos comprobados.
Orientación para resolver el caso
Relaciona el uso del chatbot con la fuente de conocimiento y el canal de derivación. Asigna comprobaciones propuestas a contenido, soporte técnico y operaciones. No declares que la actualización de la base resolverá todo ni que basta con pasar a atención manual: deben contrastarse las causas y la disponibilidad de esa alternativa. Conserva los identificadores y referencias de las fichas anteriores.
Repaso con respuestas explicadas
¿El responsable de actualizar la ficha es quien autoriza el uso?
No necesariamente. Mantener información y tomar una decisión de autorización son funciones distintas.
¿Si el modelo está disponible, el servicio funciona?
No se puede concluir solo con ese dato. También pueden intervenir fuentes, integraciones, canales de atención y personas.
¿Los datos que recibe la herramienta se utilizan siempre para entrenarla?
No debe suponerse. Es necesario contrastar el tratamiento aplicable al servicio y su configuración.
¿Una alternativa manual elimina la dependencia?
No automáticamente. Necesita medios, personas, información y autoridad. Puede depender de los mismos recursos que han fallado.
Conexión con el módulo y siguiente paso
Este mapa complementa las fichas de la lección 4.3 y la matriz del módulo 3. Es una propuesta didáctica para hacer visibles relaciones; no una evaluación completa de riesgos ni de obligaciones contractuales.
Conserva la ficha. En la lección 4.5 veremos cómo mantener el inventario cuando cambian una finalidad, un proveedor, una versión o las condiciones de operación, y cómo registrar una retirada sin perder la historia necesaria.
Escucha y aplica lo aprendido
Audio compartido por las lecciones 4.4–4.6
010. Inventario vivo de IA: dependencias, cambios y decisiones
Escucha el episodio y vuelve a la actividad de esta lección para aplicar sus ideas. Las precisiones siguientes forman parte del acompañamiento didáctico.
Consultar el punto de escucha del episodio 010 ↗ (nueva pestaña)
Este episodio tiene su punto de escucha en lección 4.6. Si ya lo has escuchado, utiliza estas notas para repasar; no hace falta repetir el audio completo.
Precisiones para aplicar el episodio
Usuarios, destinatarios y personas afectadas son perspectivas que pueden coincidir en una misma persona. Su identificación ayuda a determinar necesidades de comunicación y requisitos aplicables.
No utilizar datos para entrenamiento no garantiza su eliminación. Comprueba por separado uso, conservación, acceso y borrado; no atribuyas a una cláusula garantías que no hayas contrastado.
Un indicador verde del proveedor no demuestra la causa de un fallo ni que su API funcione correctamente en todos los aspectos. No localizar una autorización exige aclarar y escalar la situación; no demuestra por sí solo rechazo o incumplimiento. Las medidas urgentes se aplican cuando corresponda, según procedimientos y atribuciones.
La frecuencia y el equilibrio entre revisiones planificadas y por eventos dependen del contexto. También una evaluación cualitativa necesita método, criterios y evidencia suficiente.