Hazlo tuyo
El sistema solo está terminado cuando tu equipo puede operarlo sin mí.
Adopción de IA y transferencia de propiedad es la parte de cada engagement que la mayoría de los proveedores se salta: implementación con el equipo en lugar de para el equipo, diseño con humano en el circuito, formación, documentación, guardarraíles y un handover que deja a personas concretas capaces de operar, revisar y cambiar el sistema.
Inicia un proyectoIncluido en cada build. También disponible por separado para sistemas que otro construyó y dejó atrás.
En una frase
Adopción de IA y transferencia de propiedad es la fase del engagement en la que Theodoros Ampas forma al equipo de una empresa para operar un sistema de IA, documenta accesos y rutas de fallo, establece guardarraíles y puntos de revisión, y transfiere la propiedad completa para que la empresa opere el sistema en su propia infraestructura sin dependencia permanente de un constructor externo.
Un sistema que nadie del equipo puede cambiar es un alquiler con pasos extra.
Muchas empresas han pagado por una automatización, la han visto funcionar en la demo y han dejado de usarla en silencio tres meses después de que la agencia se fuera. Nadie sabía cómo cambiar una regla y nadie quería ser quien la rompiera.
La adopción no es una sesión de formación al final. Se construye desde la primera semana: las personas que operarán el sistema están en la sala cuando se diseña, y las aprobaciones son suyas desde el primer día.
Propiedad significa que el código está en tu repositorio, las cuentas son tuyas, la documentación está completa y una persona con nombre puede operarlo, revisarlo y modificarlo. Cualquier cosa menor es una dependencia disfrazada de entregable.
Qué cubre la transferencia.
Diseño con humano en el circuito
Puntos de revisión donde el criterio o el riesgo lo exigen, autonomía ganada paso a paso a partir de ejemplos aprobados, y reglas claras sobre cuándo el sistema debe preguntar.
Formación y documentación
Responsables con nombre formados con casos reales. Un runbook que cubre la operación normal, los fallos comunes y cómo cambiar una regla o un prompt con seguridad.
Guardarraíles y handover
Accesos auditados y limitados, monitorización y alertas activas, un conjunto de evaluación para detectar regresiones, y un handover formal que el equipo firma.
Del build a la independencia.
-
Durante el build
Adoptar sobre la marcha
Los responsables están en las sesiones de diseño. Las aprobaciones son suyas desde la primera ejecución real. El feedback de sus ediciones da forma al sistema.
-
Semanas 1 a 2
Formar con casos reales
Recorridos por la operación normal y por los fallos que ocurrieron durante el build. Los responsables cambian una regla y un prompt ellos mismos, conmigo observando.
-
Semanas 3 a 4
Dar un paso atrás
Dejo de tocar el sistema. El equipo lo opera. Las preguntas se responden, pero las manos en el teclado son las suyas.
-
Handover
Firmar
Auditoría de accesos, revisión de documentación, comprobación de monitorización. El equipo firma que puede operarlo. El soporte continuo, si se quiere, se acuerda aparte.
Qué significa la propiedad por escrito.
- Código en tu repositorio, sistemas en tus cuentas, límites de modelo y datos documentados.
- Un runbook que otro ingeniero podría seguir sin llamarme.
- Monitorización y un conjunto de evaluación para que el equipo sepa cuándo algo se desvía.
- Sin retainer escondido en la arquitectura. Si me quieres de vuelta, es una elección, no una necesidad.
Con qué te vas.
- Personas con nombre que pueden operar, revisar y cambiar el sistema.
- Documentación completa, mapa de accesos y runbook.
- Guardarraíles, monitorización y evaluación que se sostienen sin un constructor externo.
- Un handover firmado, y la opción, no la obligación, de soporte continuo.
Es para ti si
- Estás terminando un build y quieres estar seguro de que el equipo puede operarlo.
- Alguien te construyó un sistema de IA, se fue, y nadie se atreve a tocarlo.
- Tu consejo o un comprador preguntará quién posee y opera la IA, y quieres una buena respuesta.
Preguntas que hacen los founders
¿La transferencia está incluida en un build?
Sí. Cada build integrado y cada piloto termina con adopción y handover. Esta página describe esa fase y también la ofrece por separado para sistemas construidos por otros.
¿Puedes hacerte cargo de un sistema que construyó otro?
Normalmente. Empieza con una auditoría de accesos, código y documentación. Si el sistema no puede poseerse con seguridad, el informe lo dice y recomienda qué hacer en su lugar.
¿Y si el equipo no es técnico?
Las personas que operan el workflow rara vez lo son. Los runbooks y la formación se escriben para operadores, no para ingenieros. Cambiar una regla no debería necesitar un desarrollador.
¿Ofreces soporte continuo después?
Sí, como acuerdo aparte una vez firmado el handover. Cubre monitorización, evaluación, revisión de incidentes y mejoras supervisadas. Es opcional por diseño.
Termina el sistema como es debido.
Ya sea un build que estamos cerrando o un sistema que alguien te dejó, dime qué funciona y quién se supone que debe operarlo.
Inicia un proyecto