El ciclo de vida de la IA en la gestión de servicios
Un sistema puede seguir disponible y haber dejado de ser adecuado para su finalidad. El ciclo de vida permite revisar esa adecuación desde la necesidad inicial hasta la salida del servicio.
Actividad · Comprueba tu criterio
Mirar el servicio completo
La aplicación, el modelo y el servicio no son lo mismo. Un chatbot puede combinar una interfaz, una API externa, fuentes documentales, instrucciones, registros y una vía de soporte. El comportamiento depende de la combinación. Cambiar una fuente o una instrucción puede afectar a las respuestas aunque se mantenga el mismo modelo.
En software tradicional también cambian los datos, las dependencias y el contexto. En IA se añade la necesidad de evaluar resultados que pueden ser probabilísticos y depender de datos aprendidos y condiciones de uso. No todos los modelos aprenden durante la operación; no debemos atribuirles actualización continua por el mero hecho de ser IA.
Situar las decisiones en el recorrido
Para este curso utilizaremos el recorrido siguiente. Es una organización didáctica del trabajo, no una secuencia obligatoria ni una numeración de fases impuesta por ISO/IEC 42001. Las actividades pueden repetirse: una modificación puede exigir volver a validar, revisar el proveedor o reconsiderar el uso.
| Fase | Decisión de trabajo | Evidencia que buscar |
|---|---|---|
| Concepción | ¿Qué necesidad cubrimos y con qué límites? | Finalidad, alcance, afectados y responsable |
| Adquisición o desarrollo | ¿Qué solución y condiciones aceptamos? | Dependencias, evaluación del proveedor y requisitos |
| Validación y despliegue | ¿Puede utilizarse en este contexto? | Pruebas, criterios, aprobación y alternativa |
| Operación | ¿Sigue cumpliendo las condiciones? | Seguimiento, revisiones e incidencias |
| Modificación | ¿Qué se ha alterado y qué debemos revisar? | Solicitud, comparación, riesgos y decisión |
| Retirada | ¿Cómo cesa el uso y continúa la atención? | Plan de salida, datos, accesos y cierre |
Establecer puntos de decisión
Un punto de decisión, o gate, combina una pregunta, criterios, evidencia y una función con autoridad. No consiste en añadir una firma al final. Si el proveedor no aclara el tratamiento de las consultas, la decisión puede quedar pendiente o limitarse a una prueba con datos sintéticos, siempre que ese uso esté permitido y delimitado.
Para pasar a producción necesitamos saber qué uso se autoriza, con qué versión y configuración, qué condiciones se han probado y qué riesgos siguen presentes. La persona que ejecuta el despliegue y la función que acepta el riesgo pueden ser distintas. Documenta su relación.
Adaptar el recorrido al papel de la organización
El desarrollador controla decisiones sobre construcción y entrenamiento dentro de su ámbito. El integrador conecta componentes, fuentes y procesos, y debe comprobar esa combinación. El comprador o usuario organizativo necesita seleccionar el servicio, establecer condiciones de uso y verificar resultados en su contexto aunque no tenga acceso al entrenamiento.
Una organización puede desempeñar varios papeles. Utilizarlos aquí como categorías de gestión no determina por sí mismo su clasificación jurídica. La responsabilidad sobre una actividad se asigna expresamente; no se presume que toda ella corresponde al proveedor.
Aplicación a Tech Server IIT Spain
El chatbot ya forma parte del caso. Su recorrido requiere revisar la relación entre USO-003, las fuentes de FD-001 y los límites de SUP-001. El clasificador necesita una referencia de funcionamiento para comparar un cambio. El copiloto requiere aclarar qué información puede salir hacia la API y quién revisa sus borradores. La arquitectura exacta, los proveedores y las versiones continúan pendientes hasta disponer de evidencia.
Actividad
Construye un mapa de ciclo de vida para los tres usos. Elige dos puntos de decisión por uso y explica qué se comprueba, qué información falta, quién decide y qué ocurre si no se cumplen las condiciones.
Orientación para revisar tu propuesta
Una respuesta coherente describe el uso concreto y evita dar por conocida la arquitectura. Por ejemplo, el chatbot necesita condiciones para adquirir o continuar con la API y condiciones para cambiar su fuente o modelo. Cada decisión identifica evidencia suficiente, autoridad y una alternativa. Si falta una condición necesaria, queda pendiente; no se registra como aprobada.
Comprueba tu criterio
¿Toda IA aprende mientras se utiliza?
No. Algunos sistemas mantienen el modelo fijo durante la operación. Aun así, pueden cambiar sus entradas, fuentes, instrucciones o dependencias.
¿Un comprador puede omitir las pruebas porque el modelo lo desarrolla un tercero?
Necesita comprobar que el servicio y sus resultados son adecuados para el uso previsto. Las pruebas del proveedor pueden aportar información, pero deben valorarse respecto del contexto propio.
¿Cada modificación obliga a repetir todo el ciclo de vida?
El alcance de la revisión depende del cambio y de sus posibles efectos. Hay que justificar qué se reevalúa y qué evidencia anterior sigue siendo válida.