Menú

Contactar
Logo
Prensa

MLOps y operación de IA

Su IA cambia. ¿Quién la revisa?

Tras el piloto, los datos, los modelos y los requisitos siguen cambiando. OTOKO® implanta el control de versiones, las aprobaciones, la monitorización y un proceso de actualización definido para sus aplicaciones de IA. Su equipo sabe qué versión está en funcionamiento, cómo se evaluó su calidad y cómo puede volver a una versión anterior si surgen problemas.

Unidades de cómputo en un entorno de servidores, imagen simbólica
Modelo de operación con roles y runbooks · Planificación e implementación a cargo de OTOKO®

Su encargo a OTOKO®

Lo que hacemos por usted.

En los modelos clásicos vinculamos el código, la versión de los datos, las definiciones de las características y el artefacto del modelo. En las aplicaciones generativas se añaden además el prompt, el índice de búsqueda, las herramientas y la configuración del modelo. Un registro de modelos documenta las aprobaciones y las responsabilidades. Las credenciales de acceso no se distribuyen junto con los artefactos. Los entornos de desarrollo y de producción reciben permisos separados. Así pueden revisarse los cambios y, ante una incidencia, reconstruir los componentes realmente utilizados en lugar de limitarse a consultar el último código fuente conocido.

El posible alcance del servicio

  • Vincular las versiones de modelo, datos y configuración con las aprobaciones
  • Implantar pruebas de calidad automatizadas antes de cada despliegue
  • Monitorizar la deriva de los datos, el tiempo de respuesta y el consumo de recursos
  • Comparar las actualizaciones con la versión en producción
  • Proporcionar el inventario de IA y la documentación técnica para sus organismos de control competentes

Antes de comenzar, definimos el alcance concreto, su participación y los criterios de aceptación.

Tecnología explicada con claridad

Así llevamos a cabo la tarea.

01

Monitorizar conjuntamente la calidad, los costes y la operación

La disponibilidad técnica dice poco sobre las respuestas incorrectas desde el punto de vista del negocio. Combinamos las métricas de tiempo de respuesta, errores y consumo con señales de calidad adecuadas. La deriva de los datos indica que las entradas han cambiado, pero todavía no demuestra que los resultados hayan empeorado. Por eso, el reentrenamiento o un cambio de modelo se evalúa frente a un conjunto de prueba estable. Un despliegue gradual limita el impacto; se preparan versiones anteriores para volver atrás y posibilidades de desconexión. En el caso de modelos externos, tenemos en cuenta los cambios de versión y las interrupciones del proveedor.

02

Definir la responsabilidad de la operación y las evidencias

El alcance de la operación define horarios, canales de alerta y responsabilidades ante incidencias técnicas y de negocio. Los responsables de aprobación deciden sobre la calidad de las nuevas versiones. El traspaso incluye runbooks, un resumen de versiones y las limitaciones documentadas. Para la protección de datos y, en su caso, la normativa de IA aplicable, facilitamos información técnica a los organismos competentes; la operación por sí sola no garantiza la conformidad legal.

Sala de reuniones en la oficina de OTOKO® en Colonia

Un resultado verificable

Con este resultado puede seguir trabajando.

  1. Modelo de operación con roles y runbooks
  2. Monitorización con alertas
  3. Resumen de versiones y documentación técnica de verificación

El traspaso une la implementación y la documentación. Juntos revisamos los casos acordados y registramos las tareas pendientes.

Su proyecto en detalle

Publicar y evolucionar los modelos de forma controlada.

Construimos el camino desde el experimento hasta una operación de modelos con soporte. Las versiones de los datos, las ejecuciones de entrenamiento, los artefactos y las aprobaciones se conectan de manera que una decisión en producción siga siendo trazable incluso después de un cambio de modelo.

Diferenciar los experimentos de los modelos en producción

Un notebook suele contener supuestos implícitos sobre archivos, bibliotecas y pasos ejecutados manualmente. Trasladamos los pasos de procesamiento relevantes a flujos reproducibles con dependencias documentadas. Los artefactos del modelo reciben una versión inequívoca y una referencia a su entrenamiento, configuración y evaluación.

Un registro por sí solo no equivale a una aprobación. Definimos qué comprobaciones de calidad, seguridad y operación deben superarse antes de la publicación. La evaluación de negocio y el despliegue técnico se mantienen separados, para que un modelo técnicamente operativo no pase a producción sin una revisión de contenido.

Detectar deterioros y reaccionar de forma controlada

Durante la operación observamos la disponibilidad, los tiempos de respuesta y los cambios en los datos de entrada. Un cambio en la distribución de los datos es motivo de investigación, pero todavía no una prueba de que las predicciones hayan empeorado. Cuando los resultados de negocio solo se conocen más tarde, planificamos su incorporación posterior a la evaluación de calidad.

Los cambios de modelo se realizan con una comparación y un plan de vuelta atrás acordados. Según el caso de uso, puede tener sentido empezar con evaluaciones en modo sombra o con grupos de usuarios limitados. Si se retira un modelo, el preprocesamiento y las interfaces asociados también deben ser compatibles entre sí. Su equipo de operación recibe instrucciones para incidencias, nuevas puestas en producción y el escalado de anomalías de negocio.

Escenario de proyecto ilustrativo

Cómo ayuda el servicio en el día a día.

Ejemplo: una previsión de la demanda se reentrena cada mes. La nueva versión se comprueba primero frente a periodos de referencia fijos y a los resultados de negocio actuales. Solo una combinación aprobada de procesamiento de datos y modelo pasa a producción; la combinación anterior sigue disponible para una vuelta atrás.

Este ejemplo explica un posible desarrollo y no constituye una referencia de cliente.

Antes del primer paso

Sus preguntas sobre MLOps y operación de IA.

¿Se reentrena automáticamente cada modelo?

No. Se definen los desencadenantes y las aprobaciones necesarias. Los datos nuevos pueden no ser adecuados; una versión actualizada debe superar la comparación acordada.

¿Pueden hacerse cargo de pilotos de IA existentes?

Sí, tras realizar un inventario de permisos, flujos de datos, versiones y capacidad de prueba. Antes de hacernos cargo de ellos en producción, completamos de forma específica las bases que falten.

Su proyecto

¿Qué tarea desea resolver?

Describa su situación de partida y el resultado que desea. El servicio seleccionado se incluirá en la solicitud de contacto.

Solicitar este servicio

Nuestros socios

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Accesibilidad

Adapta la visualización a tus necesidades.

Esta página aún no tiene una versión en lenguaje sencillo.

Actualmente, los ajustes solo se aplican a esta visita. Puedes permitir que se guarden de forma permanente en Configuración de cookies.