El problema de la transferencia: lo que tu equipo debe poseer antes de que vayan los consultores
La mayoría de los proyectos de inteligencia artificial no fracasan al lanzarse, sino seis meses después, cuando nadie dentro de la empresa puede cambiar el sistema. Aquí está cómo prevenirlo.
¿Qué significa realmente la propiedad de un sistema de IA?
Un proyecto de inteligencia artificial tiene dos finales. El primero es el lanzamiento, que todos celebran. El segundo es más silencioso y llega meses después, cuando un proveedor cambia un formulario, una regulación se ajusta o se retira una versión del modelo, y el sistema comienza a dar respuestas peores. En ese momento, la pregunta es simple: ¿quién lo arregla?
Si la respuesta honesta es "tendríamos que llamar a los consultores de nuevo", no has comprado un sistema, has alquilado uno, y el contador sigue corriendo.
Las cuatro capacidades prácticas de la propiedad
La propiedad no es una carpeta de documentos entregada el último día. Son cuatro capacidades prácticas dentro de tu empresa:
- Operarlo: alguien sabe cómo verificar si funciona hoy en día y recibe notificaciones cuando no lo hace.
- Modificarlo: alguien puede ajustar una regla, agregar una fuente de documentos o actualizar un prompt sin abrir un ticket de soporte.
- Evaluarlo: alguien puede distinguir entre una buena y mala salida, con evidencia en lugar de impresiones.
- Reemplazarlo: conoces las dependencias del sistema, cuánto costaría moverlo y quién más podría realizar el trabajo.
La mayoría de los traspasos solo proporcionan la primera capacidad y omiten las otras tres. Por eso los sistemas se desvían.
La documentación que realmente importa
La documentación se escribe para cumplir con una cláusula contractual, por lo que describe una arquitectura que nadie tocará jamás y omite las cosas que la gente realmente necesita. Mantén la lista corta e insiste en estas:
- Un manual de recuperación en caso de fallo. Los cinco problemas más probables, cómo se verían desde afuera y los tres primeros pasos para cada uno. Escrito para la persona de turno, no para un ingeniero.
- Un conjunto de evaluación. Entre 100 y 200 casos reales con la respuesta correcta para cada uno, acordados por las personas que realizan el trabajo. Este es el artefacto más valioso de todo el proyecto.
- Un registro de cambios con razones. No solo lo que se configuró, sino por qué existe una regla. Las reglas sin razones serán eliminadas por la siguiente persona.
- Una hoja de dependencias y costos. Cada modelo, API y proveedor; cuánto cuesta al mes; fechas de renovación de contratos; qué pasa si desaparece.
- Un mapa de datos. ¿Dónde va cada dato, quién puede verlo y cuánto tiempo se conserva. Tus equipos legales y de seguridad necesitarán esto sin previo aviso.
Todo lo demás es opcional. Si un documento no ayuda a alguien a operar, modificar, evaluar o reemplazar el sistema, es decoración.
Las tres personas que necesitas
No tienes que contratar un equipo de aprendizaje automático. Necesitas tres individuos nombrados, y deberías nombrar a estos antes de que comience el proyecto, no durante el último mes.
- Un propietario del negocio que decida qué debe hacer el sistema y mantenga el presupuesto. Aprobó cambios y dice que no al crecimiento del alcance. Este no es un rol técnico.
- Un custodio técnico que pueda leer la configuración, realizar un cambio controlado, probarlo y ponerlo en producción. A menudo un desarrollador existente o un ingeniero de TI con capacidad asignada. No tienen que construir modelos; tienen que ser capaces de modificar y desplegar lo que existe.
- Un propietario de calidad del departamento al que sirve el sistema — el manejador de reclamos principal, la enfermera jefa, el jefe de soporte. Mantienen el conjunto de evaluación y deciden qué significa "bueno". Sin este rol, la calidad se convierte en cuestión de opinión en cuestión de semanas.
El costo total interno: por lo general, una fracción de un rol completo cada uno, una vez que el sistema esté estable. El modo de fallo no es el gasto. Es que nadie fue nombrado.
Prueba el traspaso mientras aún puedas quejarte
No aceptes la documentación como prueba del traspaso. Realiza una prueba en vivo durante las últimas semanas del compromiso, mientras los consultores aún estén bajo contrato.
Elige un cambio real — agregar un nuevo producto al conocimiento base, ajustar una regla sobre lo que el sistema se niega a responder o reemplazar una tabla de precios actualizada. Pide a tu propio equipo que lo haga, con los consultores en la sala pero en silencio. Tómalo. Luego, haz que tu propietario de calidad ejecute el conjunto de evaluación y confirme que nada más se rompió.
Si tu equipo completa eso en un día, eres dueño del sistema. Si toma una semana y tres preguntas, has encontrado exactamente las brechas para cerrar antes de que terminen las facturas. Cualquiera de los resultados es mucho más valioso que un formulario de traspaso firmado.
Incorpora esto al contrato desde el principio. Milestones de traspaso, un equipo receptor nombrado y una prueba de cambio supervisada son todos más fáciles de negociar antes de que comience el trabajo que después.
Así es como construimos en Hercules A, y significa que nuestros compromisos terminan. Y eso es el punto. La medida de un buen proyecto de IA no es cuán profundamente los consultores están incrustados un año después — es cuánta confianza tienen tus propios empleados para cambiar el sistema sin llamar a nadie.