ITINERARIO AVANZADO · MONOGRÁFICO 4 · KUMOSS · CIERRE DEL MONOGRÁFICO
Cierre · Kumoss
Relaciona necesidad, funcionamiento, límites y evidencias dentro del SGIA.
Qué has aprendido a distinguir
Kumoss convierte una necesidad expresada en lenguaje natural en trabajo sobre infraestructura como código. Coordina modelos y herramientas, utiliza el contexto disponible y conserva resultados para revisar. El aporte observable es ese recorrido técnico; el ahorro de tiempo, la reducción de incidentes y la calidad en producción requieren mediciones que esta revisión no contiene.
Generar prepara código y un plan que puede quedar fijado para aplicar. Drift ajusta código a la infraestructura observada y termina en el repositorio, sin cloud apply. Importar incorpora recursos existentes y escribe estado durante la ronda, antes de la PR posterior. Estas diferencias indican qué efectos hay que conocer y cuándo corresponde revisarlos.
La propuesta del modelo, el plan del motor, el resultado del programa y la decisión de una persona tienen funciones distintas. Un plan válido no demuestra ejecución; una incorporación en Git no demuestra aplicación; una etiqueta de completado no sustituye el resultado del motor; un informe favorable no establece por sí solo autorización organizativa. La configuración efectiva, los accesos y la conservación de información condicionan todo el recorrido.
Aplicar el razonamiento del SGIA
Para estudiar un uso concreto, empieza por su finalidad, versión y alcance. Identifica qué modo se utiliza y qué cambia durante la ronda. Relaciona las capacidades técnicas con las responsabilidades y el procedimiento aplicable. Después pregunta qué evidencia permite afirmar que el control funcionó y qué información falta para decidir.
| Pregunta de cierre | Evidencia que permitiría profundizar en una implantación |
|---|---|
| ¿Sobre qué se actuó? | Repositorio, ruta IaC, ámbito, proveedor y versiones pertinentes. |
| ¿Qué se preparó y qué se ejecutó? | Código, plan correspondiente, operación y resultado del motor. |
| ¿Qué control estaba activo? | Configuración cargada, reglas efectivas, roles y bloqueos. |
| ¿Quién podía decidir? | Atribuciones y criterio de autorización aplicables, con su registro pertinente. |
| ¿Qué ocurrió después? | Estado resultante, diferencias pendientes y decisión de seguimiento. |
| ¿Dónde quedó la información? | Destinos de datos, accesos y condiciones de conservación y recuperación. |
Las evidencias enumeradas son preguntas de evaluación, no documentos que esta revisión atribuya a una empresa. Una ausencia de información en el repositorio del producto no prueba una no conformidad organizativa. Si el procedimiento requiere una firma o un mecanismo específico, se comprobará esa condición; no se prescribe como requisito universal.
La demostración oficial permite practicar con una necesidad y un borrado publicados, sin inventar incidentes o resultados. La rúbrica pide avanzar de describir operaciones a justificar criterios y conclusiones con evidencia proporcionada. Las fichas de actividad y la matriz de correspondencia del paquete continúan ese trabajo.
Alcance que debes conservar al comunicar el estudio
Las conclusiones corresponden a una revisión estática dirigida del commit 21eb7866ac995f6d6f3159f2ea342e472893638c. No se han ejecutado servicios, modelos, pruebas ni operaciones cloud. El caso audiovisual se atribuye a la documentación oficial. El análisis aporta comprensión del diseño y de sus límites; para valorar una implantación o la conformidad de su SGIA se requieren sus evidencias y criterios propios.
Correspondencia funcional con ISO/IEC 42001
Relacionar capacidades observadas del producto con preguntas, requisitos y áreas de control que el SGIA debe valorar según su alcance y tratamiento de riesgos.
La selección y aplicabilidad de los controles se justifica en cada SGIA. La cláusula 6.3 se refiere a cambios del propio sistema de gestión. A.8 trata información a interesados y A.10 relaciones con terceros y clientes. La evidencia requerida se determina por el criterio aplicable.
| Mecanismo | Cláusulas | Área del Anexo A | Evidencia que se debe valorar |
|---|---|---|---|
| Plan fijado y aplicación | 8.1 Operación; 7.5 Información documentada. 6.3 solo si cambia el SGIA. | A.6 Ciclo de vida; A.9 Uso de sistemas de IA, según aplicabilidad. | Relación entre petición, commit, plan identificado, decisión válida, ejecución y estado posterior. Hash o firma cuando el procedimiento los exija. Comprobar cómo se protege la identidad del artefacto. |
| Revisión de cumplimiento | 8.1 Operación; 9.1 Seguimiento y evaluación; 7.5 Información documentada. | A.6 Ciclo de vida; A.9 Uso. A.8 si hay requisitos específicos de información a interesados. | Configuración efectiva, reglas y versiones de prompts activas en Phoenix, entrada evaluada, hallazgos y resultado. Pruebas de eficacia y decisión sobre sus límites. El YAML por sí solo no acredita todas las reglas efectivas. |
| Identidad y roles OIDC | 5.3 Responsabilidades y autoridad; 8.1 Operación; 7.5 Información documentada. | A.3 Organización interna; A.9 Uso. A.10 para responsabilidades de un proveedor de identidad externo, si procede. | Configuración efectiva saneada del emisor y cliente, validación de tokens, asignación y revisión de roles, propiedad y pruebas de permisos. Relación entre permisos técnicos y atribuciones de la organización; nunca adjuntar secretos. |
| Reconciliación de drift | 8.1 Operación; 8.2 y 8.3 Evaluación y tratamiento del riesgo. | A.6 Ciclo de vida; A.9 Uso de sistemas de IA. | Ámbito, código de referencia, diferencias observadas, targets, excepciones y propuesta de diff. Criterio y decisión de aceptar, excluir o corregir. La remediación cloud se evalúa por un procedimiento distinto del modo Drift. |
| Importación y estado | 8.1 Operación; 7.5 Información documentada; 8.2 Evaluación del riesgo. | A.6 Ciclo de vida; A.9 Uso de sistemas de IA. | Alcance autorizado, inventario y exclusiones, correspondencia de recursos e identificadores, cambios de estado y resultados parciales. Protección y recuperación del backend; evidencias del momento en que se autoriza cada efecto. |
| Trazas y datos del proceso | 7.5 Información documentada; 9.1 Seguimiento; 8.2 y 8.3 Riesgo. | A.6 Ciclo de vida; A.9 Uso. A.7 cuando se evalúan datos utilizados por el sistema de IA. | Mapa de datos y destinos, acceso y retención, muestra autorizada y saneada cuando exista, reglas de filtrado y pruebas de minimización. Identificar exactamente qué dato se observó; ausencia de muestra no equivale a fuga demostrada. |
| Modelos y servicios externos | 8.1 Operación; 6.1.2 y 6.1.3 Evaluación y tratamiento del riesgo. | A.10 Relaciones con terceros y clientes. | Versiones y procedencia, dependencias, licencias, condiciones del proveedor, flujos de datos, responsabilidades de actualización y aceptación de riesgos. No atribuir al proyecto la seguridad de toda su cadena sin contraste. |
| Cambios de políticas y responsabilidades del SGIA | 6.3 Planificación de cambios del SGIA; 5.3 Autoridad; 7.5 Información documentada. | A.2 Políticas de IA; A.3 Organización interna, según aplicabilidad. | Cambio del procedimiento o política, motivo, consecuencias, responsables, revisión, versión y comunicación. Si se propone automerge, política previa y comprobación por cambio mediante controles externos; no capacidad nativa acreditada. |
Hash, firma y método de autorización se justifican en el procedimiento; esta matriz no los presenta como requisitos universales ni como funciones nativas acreditadas.
IEC Vista previa e índice oficial de ISO IEC 42001 2023
BSI AI Controls Implementation Agenda