CASO 01 / IA APLICADA · PROTOTIPO DE I+D
Copiloto Investigador
Cuando el software es crítico, cada decisión necesita evidencia. Un copiloto de IA para conectar requisitos, normativa y código Ada, y orientar la revisión de calidad con trazabilidad y criterio humano.
01 / EL PROBLEMA
La calidad empieza por comprender el sistema
La documentación de un proyecto, la normativa que lo condiciona y su código suelen revisarse por separado. Mi idea fue reunir ese contexto en un copiloto que ayudara a localizar información, relacionarla y orientar la revisión diaria.
El ámbito de exploración fue el software de sistemas críticos escrito en Ada, donde una sugerencia necesita conservar su relación con las fuentes y pasar por revisión humana. El objetivo era ayudar a identificar lagunas de información, posibles tensiones entre documentación e implementación y zonas que merecieran ensayos adicionales.
Supervisión inteligente para el aseguramiento de la calidad
El objetivo de Copiloto Investigador es apoyar el aseguramiento de la calidad del software (Quality Assurance): reunir evidencias, detectar preguntas pendientes y priorizar qué necesita revisar un especialista. Su ámbito de interés incluye software empotrado y sistemas críticos, con Ada como punto de partida y SPARK como posible línea de ampliación.
Relacionar requisitos y marcos de referencia
El diseño contempla ayudar a organizar la revisión frente a referencias como DO-178C en software aeronáutico, ECSS en el ámbito espacial e ISO 26262 en automoción. Cada proyecto exigiría seleccionar los requisitos aplicables y validar el método con especialistas. El prototipo no acredita cumplimiento ni sustituye los procesos de certificación.
Incorporar nuevas señales para investigar
Como evolución se plantea incorporar métricas avanzadas de complejidad, pruebas adicionales —incluido fuzzing, o pruebas con entradas variadas y generadas— y propuestas de simplificación de código. Su utilidad tendría que demostrarse mediante ensayos: serían apoyos a la revisión, no garantías automáticas de seguridad ni capacidades ya validadas de extremo a extremo.
Referencias de alcance: EASA: ED-12C/DO-178C · ECSS: aseguramiento del software · ISO 26262: seguridad funcional en vehículos.
02 / MI APORTACIÓN
De la idea al planteamiento funcional
La idea del proyecto y su enfoque son míos. Incorporé una ontología y un grafo al planteamiento para representar conceptos y relaciones entre la información del proyecto.
La programación la realizó ChatGPT. Conté también con la ayuda de un ingeniero para pruebas. Mi aportación se centra en definir qué problema resolver y cómo debía ayudar el copiloto a comprender y revisar la información.
03 / EL RECORRIDO
De las fuentes a una decisión humana
- Preparar el contexto. Organizar documentación general y del proyecto; recuperar fragmentos relevantes y conservar su procedencia.
- Relacionar información. Combinar contexto documental y señales de análisis de código, con ontología y grafo para representar relaciones.
- Investigar. Elaborar hipótesis revisables con referencias e incertidumbre explícita.
- Supervisar. Evaluar, agrupar y priorizar las hipótesis para orientar la revisión.
- Revisar y decidir. Registrar el criterio de una persona, separado de la recomendación del sistema.
04 / UN EJEMPLO PARA ENTENDERLO
Una pregunta, con su contexto
«¿Qué documentación y señales del código conviene revisar para estudiar este requisito?»
Por ejemplo, una condición descrita en un requisito podría relacionarse con una función Ada y con un indicador de complejidad de esa función. El copiloto ayudaría a reunir esas referencias y a formular una hipótesis de ensayo para que el Supervisor orientase su prioridad.
La persona revisaría qué información sostiene la propuesta, sus supuestos y su incertidumbre antes de decidir qué investigar. Un indicador de complejidad, por sí solo, no demuestra un fallo.
Ejemplo ilustrativo del uso previsto; no reproduce un resultado obtenido en un proyecto real.
05 / TECNOLOGÍA
Información conectada y trazable
El prototipo reúne Python, recuperación de información documental (RAG), PostgreSQL con pgvector y una interfaz web. Nanobot y MCP conectan componentes y herramientas; el diseño incorpora ontología, grafo y análisis de código Ada, incluido Metrinome.
Encontrar información y entender sus relaciones
RAG permite recuperar fragmentos relevantes para una pregunta. La ontología define los conceptos del proyecto y sus relaciones; el grafo los representa para conectar requisitos, unidades de código, señales técnicas e hipótesis. El propósito es poder explicar de dónde surge una recomendación y a qué parte del proyecto se refiere.
Dar al modelo el contexto necesario
El diseño prepara conjuntos de contexto seleccionados, con referencias a sus fuentes, en lugar de enviar toda la documentación al modelo. Los artefactos persistidos conservan la información auditable y PostgreSQL facilita su consulta mediante proyecciones reconstruibles.
Incorporar señales del código
Metrinome aporta indicadores de complejidad estructural para orientar la revisión de zonas del código. Estos resultados se combinan con la evidencia documental y otras señales técnicas, manteniendo su procedencia y sus límites.
06 / CRITERIOS DE DISEÑO
Modelos, privacidad y control
El planteamiento contemplaba seleccionar los modelos según la tarea, la sensibilidad de la información y los recursos disponibles. Para documentación confidencial, se consideraba la ejecución en infraestructura propia; el uso de servicios externos quedaría condicionado a las garantías y restricciones del proyecto.
Nanobot se planteó como una capa de coordinación entre modelos y herramientas, acompañada de ejecuciones registradas, referencias a las fuentes y revisión humana. La privacidad, los permisos y la evaluación de las obligaciones normativas formaban parte de los criterios de diseño. Su validación completa para un despliegue real quedó pendiente.
07 / ESTADO Y ALCANCE
Hasta dónde llegó
El desarrollo llegó al Supervisor y al registro de revisión humana. La documentación de pruebas recoge recorridos con datos sintéticos e integración de herramientas; la demo completa con un proyecto real quedó sin terminar.
El módulo Juez quedó pendiente de integración. Su papel previsto era comparar campañas y aprovechar el feedback para proponer mejoras en futuras investigaciones. La materialización de pruebas candidatas formaba también parte de la evolución planteada; no se presenta aquí como un recorrido completo validado.
El prototipo está en pausa y no se presenta como un producto listo para producción.
Las hipótesis no son defectos confirmados. El sistema no certifica software ni sustituye la validación de especialistas.
08 / REFLEXIÓN
Por qué está en pausa
Decidí pausar el desarrollo al observar la evolución de los modelos y herramientas de IA y valorar que podían cubrir parte de las tareas previstas con una orientación adecuada. Antes de continuar, quería reconsiderar qué capacidades propias seguían aportando valor, especialmente la trazabilidad, la integración de herramientas y el control sobre los datos.
IA CON UN PROPÓSITO CONCRETO
