Construir y revisar el primer inventario de TechServe IT
Reúne lo que sabemos, relaciona sistemas y usos y convierte las lagunas en comprobaciones concretas.
Recupera las fichas de las lecciones 4.1 a 4.5. Tiempo orientativo: 15 minutos de lectura y 40 de práctica.
La lección de un vistazo
Qué sabemos y qué no debemos inventar
TechServe IT es la empresa ficticia de servicios gestionados del curso. El caso base describe un chatbot que atiende consultas de primer nivel, un copiloto que propone código y respuestas para técnicos y un clasificador que propone criticidad y destino de incidencias.
También plantea señales para investigar: recogida de datos del chatbot, propuestas técnicas inadecuadas del copiloto y prioridades sistemáticamente bajas en parte de las incidencias. Esas señales no confirman por sí solas sus causas ni el alcance de sus consecuencias.
No conocemos de forma completa proveedores, modelos, versiones, fuentes, permisos, autorizaciones o responsabilidades. Los datos ausentes se registran como pendientes. Los identificadores que utilizaremos son propuestas de organización del ejercicio.
Recuperar el alcance antes de contar elementos
Revisa el alcance que redactaste en el módulo 2. Si lo limitaste al chatbot, no incluyas silenciosamente el copiloto y el clasificador como si ya estuvieran cubiertos. Puedes analizarlos en el ejercicio como candidatos o elementos fuera del alcance actual, dejando pendiente cualquier ampliación.
Para practicar, la tabla de esta lección contempla las tres soluciones descritas en el caso. En cada registro debes indicar su relación con tu alcance: dentro, fuera con relación relevante o pendiente de determinar, explicando el motivo.
Que un elemento quede fuera del alcance no elimina una dependencia ni resuelve una situación preocupante. Registra la relación y la decisión necesaria por la vía correspondiente.
Define asimismo la cobertura de tu revisión: únicamente información del caso formativo, fichas utilizadas y ampliaciones que hayas elegido. No afirmes que has descubierto todos los usos de una empresa real.
Propuesta inicial de sistemas y usos
Mantenemos SYS-001 para el copiloto y USO-001 y USO-002 para sus dos actividades, siguiendo la propuesta de la lección 4.3. Añadimos identificadores para las otras soluciones. Las relaciones técnicas internas siguen pendientes de comprobación.
| Sistema propuesto | Uso propuesto | Lo que permite afirmar el caso |
|---|---|---|
| SYS-001 · Copiloto para técnicos | USO-001 · Proponer código | Genera propuestas técnicas; forma de revisión y posible ejecución pendientes de contraste. |
| SYS-001 · Copiloto para técnicos | USO-002 · Proponer respuestas | Prepara propuestas de respuesta; destinatarios concretos y forma de envío pendientes. |
| SYS-002 · Chatbot de atención | USO-003 · Atender consultas de primer nivel | Uso descrito en el caso; datos, fuentes, límites y circuito de atención humana por aclarar. |
| SYS-003 · Clasificador de incidencias | USO-004 · Proponer criticidad y destino | Clasifica incidencias; aplicación y corrección de sus propuestas pendientes de comprobar. |
Esta propuesta tiene tres fichas de sistema y cuatro de uso. No demuestra que existan tres modelos ni tres proveedores, ni obliga a mantener esa estructura si nuevas evidencias aconsejan cambiarla.
Separamos provisionalmente código y respuestas para poder investigar sus distintas condiciones. Mantenemos criticidad y destino en un mismo uso inicial porque el caso los presenta dentro de la clasificación de incidencias. Si requieren decisiones o condiciones diferenciadas, puedes separarlos y justificarlo.
Montar el expediente de trabajo
- Nota de cobertura. Describe el alcance de referencia, las fuentes utilizadas y las limitaciones de este ejercicio.
- Fichas de sistemas. Identifica cada solución y los datos compartidos conocidos o pendientes.
- Fichas de usos. Concreta finalidad, personas, entradas, salidas, aplicación y estados, enlazando los sistemas.
- Relaciones y dependencias. Registra qué sostiene cada uso, qué está confirmado y qué debes investigar.
- Hallazgos y comprobaciones. Convierte las lagunas en acciones con una función responsable propuesta y un momento de revisión.
- Un cambio o retirada simulados. Aplica el método de la lección 4.5, conservando por separado el estado inicial del caso.
Reutiliza tus fichas anteriores. Si encuentras contradicciones, conserva la referencia a lo que has corregido y explica el motivo. No copies cuatro veces un dato común del sistema si puedes mantener una referencia única.
En un servicio real, las evidencias pueden residir en herramientas distintas. El expediente debe permitir localizarlas con los permisos pertinentes, no reunir copias indiscriminadas de información sensible.
Revisar el inventario con preguntas concretas
| Revisión | Qué comprobar | Qué hacer si falta |
|---|---|---|
| Identidad | Cada ficha tiene un identificador y no se confunde con otra. | Aclarar duplicados y relaciones, conservando referencias anteriores. |
| Finalidad | El uso describe una actividad concreta y su relación con el alcance. | Consultar el proceso y marcar los límites pendientes. |
| Aplicación de la salida | Se sabe qué produce y cómo se utiliza, o se declara la duda. | Preparar una comprobación con quien realiza la tarea. |
| Responsabilidad | Se distinguen funciones confirmadas y asignaciones propuestas. | Solicitar confirmación a la autoridad competente. |
| Estados | No se mezclan operación, autorización y calidad del registro. | Separar la información y localizar la evidencia correspondiente. |
| Dependencias | Las relaciones describen una aportación y su fuente. | Investigar las conexiones sin inventar arquitectura. |
| Mantenimiento | Hay fechas, fuentes e información sobre cambios y pendientes. | Definir quién actualizará y qué activa la revisión. |
Utiliza tres resultados de revisión: «coherente con la información disponible», «pendiente de comprobar» y «requiere corrección». Son categorías del ejercicio, no una calificación de conformidad normativa.
Una ficha puede ser coherente y seguir incompleta. El problema no es reconocer desconocimiento; es ocultarlo o dejarlo sin una siguiente acción cuando afecta a una decisión.
Ordenar las comprobaciones pendientes
La prioridad inicial debe explicarse a partir de las posibles consecuencias y de la incertidumbre que necesitas resolver. No asignes una categoría formal de riesgo sin su evaluación.
Ejemplo de razonamiento: averiguar si las propuestas de código pueden ejecutarse directamente puede ser prioritario porque cambia la exposición y las posibilidades de intervención. Pero no sabemos que esa ejecución directa exista.
En paralelo, confirmar cómo se aplican las prioridades del clasificador puede resultar urgente si hay indicios de que afectan a la atención de incidencias relevantes. La información nueva puede cambiar el orden.
Para cada pendiente, anota: pregunta, motivo, fuente a consultar, función responsable propuesta, resultado esperado y momento de revisión. Si hay señales de un incidente en curso, utiliza el circuito de respuesta del servicio; no esperes a terminar el inventario.
La disponibilidad de un interlocutor o la facilidad de obtener un dato influyen en el plan de trabajo, pero no deberían ocultar las cuestiones con mayores consecuencias potenciales.
Mantener las ampliaciones hipotéticas separadas
Las lecciones anteriores introdujeron escenarios para practicar. Puedes incorporar uno a esta actividad, siempre que lo identifiques como ampliación y no lo mezcles con los hechos del caso base.
- Lección 4.2: una función de resumen declarada por una técnica. Es un candidato que requiere contraste; no un nuevo uso confirmado por defecto.
- Lección 4.4: una fuente de conocimiento y una cola de derivación con problemas. Sirven para practicar relaciones y dependencias; su arquitectura pertenece a ese escenario hipotético.
- Lección 4.5: pasar de borradores revisados a envío directo. La revisión humana inicial se daba por confirmada únicamente dentro de esa ampliación del caso.
Documenta el estado anterior y el cambio supuesto, las fichas afectadas y las decisiones necesarias. No sustituyas el inventario inicial por una situación que todavía estás proponiendo.
Tu actividad integradora
Reúne las plantillas anteriores y completa esta hoja de integración. La hoja resume el expediente y su revisión; no sustituye las fichas de sistema, uso, dependencias y cambios.
Propuesta de resolución razonada
Una estructura inicial coherente
Conserva SYS-001 para el copiloto y vincula USO-001 y USO-002. Propón SYS-002/USO-003 para el chatbot y SYS-003/USO-004 para el clasificador. Explica que la descomposición es inicial y que no conocemos las relaciones técnicas entre las soluciones.
Si tu alcance se limita al chatbot, márcalo en la cobertura: las otras fichas son material de investigación o propuestas fuera del alcance actual, no una ampliación aprobada.
Datos que deben permanecer pendientes
Proveedor, modelo, versión, datos concretos, autorización y funciones no confirmadas. Tampoco debe afirmarse que las salidas se ejecutan automáticamente o que todas se revisan. Asigna preguntas y fuentes para obtener esa información.
Cómo tratar los avisos del caso
Las propuestas inadecuadas y las prioridades bajas justifican investigar cómo se generan y aplican los resultados. No prueban por sí solas un fallo del entrenamiento, una discriminación concreta ni una falta de autorización. Conserva las señales y plantea comprobaciones proporcionadas.
Cómo incorporar el cambio simulado
Registra la propuesta de envío directo como una ampliación del escenario. Identifica los campos afectados —aplicación de salidas, intervención humana, integración y autorización— y las decisiones necesarias. Mantén diferenciados lo previsto, lo decidido y lo comprobado.
Una conclusión que no exagera el resultado
«Se ha preparado un inventario inicial a partir del caso formativo, con tres fichas de sistema y cuatro de uso propuestas. La relación con el alcance queda identificada. Persisten dudas sobre componentes, datos, aplicación de salidas y autorizaciones; se han definido comprobaciones. El resultado permite orientar la investigación, pero no acredita seguridad, conformidad ni autorización de despliegue».
Adapta la conclusión a tu trabajo: no copies cifras o afirmaciones si tu estructura es distinta.
Criterios para dar por terminada la actividad
- Tu inventario describe actividades concretas y relaciona sistemas y usos.
- La cobertura es compatible con el alcance o identifica decisiones pendientes.
- Hechos, hipótesis y propuestas se distinguen con claridad.
- Los estados y responsabilidades no se presuponen.
- Las dependencias y fuentes pueden seguirse mediante referencias comprensibles.
- Las lagunas relevantes tienen acciones y responsables propuestos.
- El cambio simulado conserva la historia y las decisiones pendientes.
- La conclusión explica lo conseguido y sus límites.
Puedes terminar el ejercicio con datos pendientes si los has identificado y gestionado de forma razonada. No equivale a dar por preparado un sistema para operar. Si un compañero revisa tus fichas, pídele que señale qué entiende, qué no puede comprobar y dónde encontraría la evidencia.
Qué nos llevamos al siguiente módulo
Ahora disponemos de una base para preguntar qué puede ocurrir, a quién puede afectar y qué información necesitamos para valorarlo. En el módulo 5 trabajaremos la identificación y clasificación de riesgos e impactos apoyándonos en estas fichas.
Con esta actividad termina la secuencia escrita de las seis lecciones del módulo 4. La infografía y el audio de apoyo están incorporados a esta lección. Revisa sus precisiones y completa la actividad antes de avanzar.
Caso ficticio y propuesta didáctica de José Manuel Hernández Agudo. La actividad no reproduce una comprobación exhaustiva de requisitos de ISO/IEC 42001.
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.
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.