Empieza sin malicia. Alguien de tu equipo construye con Claude una herramienta pequeña, en una cuenta personal o dentro de un artefacto de chat: presupuestos sacados de una hoja de cálculo, un resumidor de solicitudes de aprobación, un revisor de documentos de carga. Funciona. Un compañero pide el enlace. Después su equipo. En un trimestre, un flujo que corría a base de copiar y pegar ahora corre sobre esta cosa, y nadie firmó nada.
La propiedad se decide el día en que nace la aplicación, no el día en que IT pregunta. De quién es el código, dónde viven los datos, qué pasa cuando cambia el prompt, quién responde si alucina, qué exigirá IT antes de dejarle tocar datos de la empresa: esas preguntas cuestan casi nada de responder el día uno, y mucho cuando la herramienta ya tiene usuarios.
Las preguntas que nadie hizo al principio
¿De quién es el código? Construida en una cuenta personal, la app vive en una zona gris entre el autor, la empresa y los términos de consumo de la plataforma. Las suscripciones de consumo están pensadas para individuos, no para empresas, así que los términos de propiedad, datos y soporte que necesita un negocio no suelen estar en el plan donde nació la herramienta.
¿Dónde viven los datos? Si los compañeros pegan registros de clientes, hojas de precios o cláusulas de contratos en un chat personal para hacer útil la herramienta, los datos de la empresa han salido de su control, y quizá de su región. La residencia de los datos es una conversación mucho más barata antes de que existan en el lugar equivocado.
¿Qué pasa cuando cambia el prompt? El prompt es la lógica de la aplicación. Cambia un párrafo y el comportamiento se desplaza para todos los usuarios el lunes por la mañana, sin historial de versiones, sin nota de entrega y sin vuelta atrás. Los compañeros que dependen de la herramienta pasan a depender de algo que puede cambiar en silencio de un día para otro.
¿Quién responde si alucina? Un presupuesto equivocado con pinta de correcto o una cláusula mal resumida es inofensivo en una demo y trascendente en una decisión. Sin evidencia de evaluación ni registro de lo que produjo la herramienta, nadie puede reconstruir siquiera qué falló, y menos decidir quién es responsable.
¿Qué exigirá IT? Autenticación, matriz de accesos, trazas de auditoría, copias de seguridad y restauración, un acuerdo de tratamiento de datos, un responsable de soporte con nombre: la revisión llega en cuanto la herramienta importa. Las apps que pueden pasar la revisión la sobreviven. Las que hay que reconstruir bajo presión, muchas veces no.
Cinco cosas para revisar hoy
Si algo de esto describe a una herramienta de tu organización, cinco revisiones ocupan una tarde:
- Cuenta y rutas de exportación. ¿En qué cuenta se construyó la app, y pueden salir el código y los datos en un formato utilizable, hoy, sin la buena voluntad de nadie?
- Residencia de los datos. ¿Qué datos de la empresa han pasado por cuentas personales, y qué decían sobre ello los términos vigentes en su momento?
- Control de acceso. ¿Quién puede llegar hoy a la herramienta, quién puede ver lo que almacena, y es esa la lista que elegirías?
- Evidencia de evaluación. ¿Cómo sabes que la herramienta acierta en tus casos? Ejemplos de referencia, comprobaciones puntuales, un registro de lo que produjo para usuarios reales: cualquier evidencia vale más que un encogimiento de hombros.
- Un plan de salida. Si mañana el autor no está disponible, ¿quién puede reconstruir, operar y defender la herramienta? Si la respuesta es nadie, tienes un punto único de fallo con cara amable.
Dos rutas a producción
La solución no es matar la herramienta. El instinto que la construyó era correcto: el flujo merecía automatizarse y alguien lo demostró barato. La solución es darle a la app lo que necesita el software: un dueño, un entorno, controles y evidencia para las personas cuyo trabajo es el riesgo.
Hay dos rutas limpias, y las dos empiezan con la misma revisión de preparación breve a precio fijo de lo que de verdad tienes, con un precio firme y por escrito antes de comprometer nada. La ruta uno es alojamiento gestionado en la UE: la app sigue corriendo, ahora dentro de una plataforma gestionada con entornos separados de pruebas y producción, acceso autenticado, almacenamiento cifrado, copias de seguridad con restauraciones ensayadas, y las matrices de acceso e historiales de versiones que pedirá tu equipo de IT. Un primer piloto corre en unas tres semanas. La ruta dos es un traspaso documentado a IT: la app se adapta a un entorno corporativo que elijas, con documentación completa y un traspaso ensayado, y la opera tu gente. En cualquier caso, quien la construyó sigue construyendo. El objetivo de la producción es proteger lo que hizo, no confiscarlo.
Ejecutamos ambas rutas como Claude App to Production, y la revisión de preparación produce un precio firme y por escrito para tu aplicación concreta antes de que te comprometas.
El mejor día para responder las preguntas de propiedad fue el día en que nació la aplicación. El segundo mejor día es hoy, mientras las respuestas siguen baratas.