El piloto empresarial de vibe coding en 30 días

Un piloto empresarial de vibe coding debe demostrar que el equipo puede operar, inspeccionar, recuperar y abandonar la plataforma en condiciones parecidas a producción. Generar rápidamente una aplicación atractiva es útil, pero responde a la pregunta menos costosa de la evaluación.

Un contrato debe depender de resultados documentados de aprobado o suspendido para la exportación del código fuente, el control de acceso, la ubicación de datos, el despliegue, la reversión, los registros de auditoría y el traspaso a desarrolladores. Si el proveedor controla la prueba, justifica resultados ambiguos o aporta pasos faltantes durante el ejercicio final, el piloto ha medido la ayuda del proveedor, no la preparación empresarial.

El piloto mide el coste de salida además de la velocidad de creación

El piloto necesita un plan de aceptación cerrado antes de que alguien empiece a crear. De lo contrario, cada resultado incómodo se convierte en una petición de más tiempo, una interpretación más limitada o una promesa de que la próxima versión lo resolverá.

Elige una aplicación de referencia que sea lo bastante pequeña para terminarla, pero lo bastante compleja para revelar riesgos operativos. Debe tener varios roles de usuario, límites entre clientes, registros persistentes, gestión de archivos, un servicio externo, trabajo en segundo plano, secretos y al menos una migración de base de datos. Un sitio informativo demuestra muy poco sobre una plataforma de aplicaciones empresariales.

Registra cada prueba en un archivo de evidencias almacenado fuera de la plataforma. Una estructura sencilla permite revisar el resultado:

pilot:
  application: claims-intake-reference
  revision: 8f21c6a
  test_owner: enterprise-architecture
  vendor_observer: true
controls:
  source_export:
    result: pending
    evidence: []
    blocker_if_failed: true
  access_control:
    result: pending
    evidence: []
    blocker_if_failed: true
  data_location:
    result: pending
    evidence: []
    blocker_if_failed: true
exceptions:
  owner: procurement
  expires: 2026-09-30
  compensating_control: null

La revisión identifica la aplicación exacta sometida a prueba. Cada entrada de evidencia debe apuntar a material que controle tu equipo, como un archivo exportado, una transcripción de terminal, un archivo de registro, una configuración de identidad, tiempos de recuperación o una respuesta firmada del proveedor. Las capturas de pantalla pueden respaldar un resultado, pero rara vez lo prueban por sí solas, porque omiten solicitudes, códigos de respuesta, historial de configuración y el contexto circundante.

Separa las condiciones de las preferencias. La portabilidad, el aislamiento entre clientes, la capacidad de recuperación, la ubicación de datos y la integridad de auditoría suelen pertenecer a la categoría de condiciones. La comodidad del editor y la velocidad de generación pueden influir en la adopción, pero una puntuación alta en esos aspectos no puede compensar una prueba de aislamiento fallida. Promediar todos los resultados en una única puntuación optimista es un error habitual de compras, porque permite que diez aprobados cosméticos oculten un fallo peligroso.

Asigna un responsable empresarial a cada control y una persona que pueda declarar el fallo. El proveedor puede observar y corregir errores de hecho, pero no debe calificar su propio trabajo. Registra cualquier ayuda que preste. Si el personal del proveedor repara la exportación, modifica una política u opera la reversión, repite la prueba sin su participación antes de marcarla como aprobada.

Un calendario de 30 días funciona cuando el equipo prueba evidencias de forma continua. Cierra el alcance y crea pronto la aplicación de referencia, luego reserva tiempo suficiente para pruebas destructivas, reconstrucciones en entornos limpios, fallos de identidad, ejercicios de restauración y traspaso. Los equipos que desarrollan hasta el día 28 suelen pasar la reunión final hablando de funcionalidades que nunca probaron.

La exportación del código fuente debe producir una compilación independiente

La exportación del código fuente se aprueba solo cuando la empresa puede compilar, probar, ejecutar y modificar la aplicación en un entorno limpio sin acceso a la plataforma. Tener un directorio lleno de código no equivale a tener una aplicación portátil.

Exporta una revisión fijada, registra su suma de verificación y llévala a un repositorio nuevo controlado por la empresa. Usa una máquina limpia o un trabajador de compilación desechable sin cookies del proveedor, credenciales de comandos, caché de paquetes, archivos generados ni variables de entorno ocultas. El desarrollador receptor debe tener únicamente la exportación y su documentación.

Ejecuta los comandos declarados por el repositorio, no los comandos proporcionados en una reunión. Para una aplicación React y Go, una transcripción podría tener esta forma:

$ npm ci
added 428 packages, and audited 429 packages
$ npm test
Test Suites: 18 passed, 18 total
$ go test ./...
ok   example/api/auth
ok   example/api/orders
$ go build ./cmd/server
$ ./server
configuration error: DATABASE_URL is required

Ese error final es un aprobado útil, no una vergüenza. Demuestra que el programa nombra una dependencia que falta en vez de conectarse silenciosamente a un servicio del proveedor. Tras proporcionar la configuración documentada, el equipo debe iniciar la aplicación, aplicar migraciones, crear un usuario, probar una integración externa mediante un doble de prueba y ejecutar las pruebas automatizadas.

The Twelve-Factor App indica que una aplicación debe seguir una única base de código en control de versiones y declarar explícitamente sus dependencias. Estas reglas siguen siendo útiles, pero no resuelven la portabilidad. Las aplicaciones generadas pueden declarar dependencias públicas y aun así depender de intermediarios de identidad propietarios, metadatos de despliegue, funciones alojadas, complementos de compilación o endpoints de ejecución. Tu prueba debe encontrar esas dependencias y clasificar cuáles se pueden sustituir.

Inspecciona la exportación en busca de mapas de código fuente, clientes generados, archivos de migración, datos de prueba, definiciones de compilación, avisos de licencia, configuración de infraestructura y un archivo de bloqueo de dependencias. Busca direcciones de servicio codificadas directamente, componentes binarios opacos, secretos copiados e importaciones que solo se resuelvan dentro de la plataforma. El equipo también debe saber qué artefactos tiene derecho contractual a utilizar tras la terminación. La posesión técnica no corrige la falta de derechos.

La portabilidad de la base de datos merece su propia comprobación dentro de esta condición. La documentación de PostgreSQL explica que pg_dump exporta una base de datos y produce una instantánea coherente, pero no exporta objetos de todo el clúster, como los roles. Un equipo que restaure solo la base de datos de la aplicación puede descubrir que han desaparecido las suposiciones sobre propiedad y permisos. Prueba la creación del esquema, los datos iniciales, la recreación de roles, las extensiones y una restauración en una instancia de PostgreSQL controlada por la empresa.

Aprueba cuando un desarrollador que no conoce el sistema puede reproducirlo en funcionamiento a partir de la exportación usando instrucciones escritas y sustituir cada dependencia de ejecución del proveedor o identificar un sustituto aceptado. Suspende cuando faltan archivos, las compilaciones llaman a servicios privados, el historial del esquema no puede recrear la base de datos, aparecen secretos en el archivo exportado o el proveedor debe intervenir. Una futura función de exportación en una hoja de ruta no cambia el resultado.

El control de acceso debe resistir solicitudes directas

El control de acceso se aprueba cuando el servidor deniega cada operación no autorizada incluso si un usuario evita la interfaz generada. Ocultar un botón, una ruta o un elemento de menú prueba la presentación, no la autorización.

Define roles y recursos antes de generar la aplicación. Usa una matriz de permisos pequeña que incluya límites entre clientes y acciones sensibles:

Ejecuta cada denegación desde el navegador y llamando directamente a la API. Cambia identificadores de objeto, identificadores de cliente, filtros de consulta y cuerpos de solicitud. Prueba los endpoints masivos por separado, porque los equipos suelen proteger la ruta de un único registro y olvidan las rutas de exportación, búsqueda, adjuntos y actualización por lotes. Verifica la aplicación de reglas en el servidor después de que un cambio del cliente elimine todas las restricciones visuales.

OWASP Application Security Verification Standard 4.0 sitúa la verificación de control de acceso en capas de servicio fiables y espera que el acceso se deniegue por defecto. Este consejo importa aún más en sistemas generados, porque una interfaz pulida puede crear una confianza falsa. He visto equipos aceptar una demostración de roles en la que el usuario restringido no tenía botón de edición, para descubrir después que ese mismo usuario podía enviar manualmente la solicitud de edición.

La autenticación y la autorización requieren dictámenes separados. La autenticación establece quién presentó una credencial. La autorización decide si esa identidad puede realizar esta acción sobre este objeto en este momento. El inicio de sesión único puede aprobarse mientras la autorización sobre objetos falla entre todos los clientes.

Conecta el proveedor de identidad empresarial y prueba los casos de alta, cambio y baja. Crea un usuario, cambia su grupo, elimina un rol elevado, desactiva la cuenta y revoca las sesiones activas. Mide cuánto tarda cada cambio en afectar a la aplicación. Prueba cuentas locales de emergencia, identidades de servicio, credenciales de API y administradores de plataforma en lugar de limitar el ejercicio a usuarios normales de la aplicación.

OpenID Connect Core define la reclamación sub como un identificador localmente único que nunca se reasigna dentro del emisor. Almacena y audita ese identificador estable junto con un nombre de inicio de sesión legible. Las direcciones de correo y los nombres visibles cambian, por lo que usarlos solos puede corromper el historial de propiedad o hacer que dos personas distintas parezcan idénticas después de reutilizar una cuenta.

Suspende la condición si cualquier usuario con menos privilegios puede cruzar un límite entre clientes, si el acceso administrativo evita una aprobación registrada, si los privilegios eliminados persisten más allá del intervalo acordado o si el equipo no puede explicar quién puede acceder a datos de producción. Trata a un administrador del proveedor como una vía de acceso, incluso cuando el acceso se produce mediante herramientas de soporte y no desde la aplicación.

La ubicación de datos necesita un mapa por componente

La ubicación de datos se aprueba solo cuando el equipo puede identificar cada copia relevante, procesador, transferencia, copia de seguridad y vía de soporte. Elegir un país para la carga de trabajo de la aplicación prueba la ubicación de esa carga, no la ubicación de todos los datos relacionados.

Empieza por categorías en lugar de una pregunta imprecisa sobre residencia. Incluye registros de clientes, archivos cargados, credenciales, prompts, código generado, metadatos de la plataforma, registros, trazas, solicitudes y respuestas del modelo, copias de seguridad, adjuntos de soporte y analítica. Para cada categoría, registra dónde entra, dónde permanece, qué servicio la procesa, cómo se mueve, cuánto tiempo se conserva y quién puede acceder a ella.

Esta distinción detecta un error rutinario: la residencia de datos, la ubicación del procesamiento y el control de transferencias son afirmaciones relacionadas, pero distintas. Una base de datos puede residir en un país mientras la inferencia del modelo, el análisis de telemetría, el acceso de soporte o la recuperación ante desastres crean una transferencia a otro lugar. El lenguaje de compras que dice que los datos están «alojados» en una región suele dejar esas vías sin respuesta.

Usa un marcador preparado para cada categoría, como una cadena única del proyecto o un identificador de registro sintético. Pide al proveedor que muestre dónde puede aparecer ese marcador en el almacenamiento de la aplicación, los registros operativos, las copias de seguridad, los sistemas de soporte y el procesamiento del modelo. No incluyas datos personales reales o regulados en el piloto hasta que los revisores legales y de seguridad acepten el mapa.

Solicita evidencia documental sobre subprocesadores, regiones de procesamiento, acceso de soporte, retención, eliminación, titularidad del cifrado y recuperación ante desastres. Una garantía verbal en una llamada comercial debe seguir siendo un punto abierto. Si la plataforma usa varios proveedores de modelos, determina si la empresa puede seleccionarlos o restringirlos, dónde procesa cada uno las solicitudes y si los prompts o resultados quedan sujetos a alguna retención del proveedor.

Prueba la eliminación como un proceso observable. Elimina un registro preparado y pregunta después qué permanece en el almacenamiento activo, los registros, las instantáneas, las copias de seguridad y el material de auditoría exportado. La eliminación inmediata de todas las copias de seguridad puede no ser posible ni deseable, pero el proveedor debe indicar con precisión la retención y el comportamiento de expiración final. El equipo legal decide si ese comportamiento cumple la obligación; el equipo del piloto registra lo que ocurre en realidad.

Aprueba cuando el mapa de datos es lo bastante completo para que los revisores de seguridad, privacidad y legal aprueben cada vía, y cuando la configuración coincide con la ubicación documentada. Suspende cuando el proveedor responde solo por la base de datos principal, no puede identificar ubicaciones de procesamiento del modelo, permite acceso de soporte sin explicación o trata la geografía de las copias de seguridad como confidencial. Una ubicación sin resolver no demuestra una ubicación aceptable.

El despliegue debe ser repetible fuera de una sola sesión de navegador

El despliegue se aprueba cuando el equipo puede publicar una revisión fijada mediante un proceso documentado y repetible, y demostrar exactamente qué llegó a cada entorno. Una URL de vista previa que funciona no establece control de lanzamiento.

Crea entornos separados, similares a pruebas y producción, con identidades, secretos, bases de datos, dominios y reglas de aprobación distintos. La misma revisión de código debe pasar entre ellos sin copiar estado oculto del editor. La configuración puede diferir, pero la diferencia debe estar declarada y ser revisable.

Despliega dos veces la misma revisión desde un estado limpio. Captura la revisión de código fuente, las sumas de verificación de bloqueo de dependencias, el resultado de la compilación, la versión de migración, las referencias de configuración, el aprobador, el encargado del despliegue, las horas de inicio y finalización, el entorno de destino, el resultado de la comprobación de estado y el identificador de lanzamiento resultante. Después compara los registros. Si la misma entrada produce software sustancialmente diferente, el equipo necesita una explicación antes de usarlo en producción.

Un registro de lanzamiento puede tener esta forma compacta:

{
  "release_id": "rel-1042",
  "source_revision": "8f21c6a",
  "environment": "pilot-prod",
  "schema_version": "20260728_03",
  "requested_by": "oidc:00u81c",
  "approved_by": "oidc:00u19a",
  "result": "succeeded",
  "health_check": "passed"
}

Haz que el despliegue falle a propósito. Elimina un secreto necesario, rompe una migración, deniega el acceso a un servicio externo y provoca el fallo de una comprobación de estado. El sistema debe detenerse de forma segura, indicar qué fase falló, conservar evidencia de diagnóstico y evitar presentar un lanzamiento parcial como saludable. Una interfaz de despliegue que solo informa «fallido» deja a los operadores adivinando durante un incidente.

Prueba la separación de funciones si la política lo exige. La persona que cambia el código de producción no debe concederse silenciosamente una aprobación personal ni modificar el registro de auditoría. Determina también si los administradores de plataforma, los administradores de aplicaciones generadas y los operadores de nube tienen autoridad separada. Estos roles suelen concentrarse durante una demostración porque una cuenta lo crea todo.

Aprueba cuando otro operador autorizado puede desplegar una revisión elegida, ver sus referencias de configuración, identificar sus aprobaciones y confirmar su estado sin ayuda del proveedor. Suspende cuando el despliegue depende de la sesión de chat original, de una versión más reciente sin nombre, de credenciales personales, de artefactos generados mutables o de trabajo manual no documentado.

La reversión debe abarcar código, esquema, datos y efectos secundarios

La reversión se aprueba cuando restaura un estado de servicio definido dentro del tiempo acordado y mantiene la pérdida de datos dentro del límite acordado. Revertir solo el código de la aplicación puede empeorar un incidente si la base de datos o un efecto externo ya han avanzado.

Establece un objetivo de tiempo de recuperación y un objetivo de punto de recuperación antes del ejercicio. El tiempo de recuperación mide cuánto puede permanecer interrumpido el servicio. El punto de recuperación mide cuántos datos confirmados puede perder el negocio. Los equipos dicen con frecuencia «la reversión tardó seis minutos» sin comprobar si desaparecieron registros recientes, lo que informa solo de la mitad del resultado.

Usa una versión deliberadamente incompatible. La versión A almacena el estado de un cliente como texto. La versión B lo migra a una nueva tabla, cambia la API, emite una notificación mediante un servicio de prueba e inicia una conversión en segundo plano. Añade registros antes, durante y después del lanzamiento, interrumpe la conversión y activa la reversión.

El primer fallo suele aparecer cuando la versión A se inicia con el esquema de la versión B. El código antiguo espera una columna que la migración eliminó. Restaurar solo la aplicación provoca por tanto una segunda caída. Restaurar una instantánea de la base de datos puede recuperar la versión A, pero puede descartar registros confirmados después de la instantánea. Reproducir esos registros puede duplicar la notificación externa a menos que la integración use un mecanismo de idempotencia.

El equipo debe elegir un diseño de recuperación en lugar de asumir que un método sirve para cada lanzamiento. Las migraciones compatibles de expansión y contracción pueden permitir que el código antiguo y el nuevo se ejecuten con el mismo esquema. Una reparación hacia adelante puede ser más segura que una reversión después de una transformación de datos irreversible. La restauración de instantáneas puede funcionar cuando el negocio acepta su punto de recuperación y el equipo ha probado la reproducción. Registra qué método aplica a cada clase de migración.

Durante el ejercicio, captura la hora de detección, la hora de decisión, el operador, la aprobación, la versión de la aplicación, la versión del esquema, la identidad de la instantánea, los registros restaurados, los registros perdidos, el resultado de la reproducción, los trabajos en cola y las llamadas externas. Valida el comportamiento de negocio después de que las comprobaciones técnicas de estado se aprueben. Un monitor de procesos en verde no demuestra que los permisos, saldos, adjuntos o estado del flujo de trabajo sigan siendo correctos.

Aprueba cuando los operadores ejecutan la vía de recuperación documentada sin intervención del proveedor, cumplen ambos objetivos de recuperación, concilian los registros y explican cada efecto externo. Suspende cuando la reversión es un botón sin etiqueta, se desconoce la compatibilidad del esquema, las instantáneas no se pueden restaurar en un entorno aislado o el equipo no puede calcular la pérdida de datos.

Los registros de auditoría deben reconstruir una acción disputada

La capacidad de auditoría se aprueba cuando un investigador puede determinar quién hizo qué, sobre qué objeto, cuándo, desde dónde, con qué resultado y bajo qué autoridad. Un feed cronológico de actividad diseñado para la colaboración de proyectos no es necesariamente un registro de auditoría.

NIST SP 800-53 Revision 5 separa la gestión de cuentas en AC-2 del registro de eventos y la generación de registros de auditoría en los controles AU. Esa separación tiene sentido. La administración de identidades determina qué principal tenía acceso, mientras la generación de auditoría registra cómo usó ese acceso. Necesitas ambos historiales para investigar un despliegue o una exportación de datos disputados.

NIST AU-3 exige registros que contengan el tipo de evento, la hora, el lugar, el origen, el resultado y la identidad asociada. Para este piloto, añade cliente, objeto objetivo, correlación de solicitudes, valores anteriores y nuevos relevantes para la seguridad, contexto de autenticación y referencia de aprobación cuando corresponda. No registres valores secretos, tokens de sesión, prompts completos que contengan datos restringidos ni cuerpos de registros sensibles solo para que el registro parezca completo.

Un evento útil debe parecerse a esto:

{
  "event": "role.assignment.changed",
  "time": "2026-07-28T14:03:22Z",
  "actor_sub": "oidc:00u81c",
  "actor_role": "platform-admin",
  "tenant": "tenant-204",
  "target": "user-771",
  "change": {"from": "viewer", "to": "manager"},
  "outcome": "success",
  "request_id": "req-9918",
  "approval_id": "apr-118"
}

Genera eventos para fallos de autenticación, cambios de rol, revocación de sesiones, acceso a secretos, exportación de código fuente, exportación de datos, cambios de configuración, despliegue, reversión, uso de instantáneas, cambio de dominio, acceso de soporte, exportación de auditoría y cambios en la configuración de auditoría. Prueba los intentos fallidos además de los éxitos. Un investigador suele necesitar la denegación que precedió a un cambio de privilegio exitoso.

Cambia el nombre visible y el correo electrónico de un usuario, y después verifica que los eventos anteriores sigan vinculados a la identidad estable. Compara los eventos de la plataforma con los de la aplicación y los registros del proveedor de identidad mediante una referencia compartida de solicitud o sesión. Comprueba la coherencia de los relojes, porque un desfase de cinco minutos puede invertir el orden aparente de la aprobación y el despliegue.

Intenta modificar, eliminar, desactivar y saturar el flujo de auditoría con el rol más fuerte del piloto. Verifica la retención, el formato de exportación, la paginación, la zona horaria, el filtrado y el retraso antes de que los registros se puedan buscar. Exporta los registros a almacenamiento controlado por la empresa y confirma que la exportación contiene nombres de campos estables adecuados para la investigación. Una hoja de cálculo descargable puede ayudar a un analista, pero no debe ser la única representación si las celdas truncan valores estructurados.

Aprueba cuando un revisor que no asistió a la prueba puede reconstruir un incidente preparado a partir de evidencias exportadas y detectar intentos de debilitar el registro. Suspende cuando los administradores pueden borrar su propio rastro, las identidades no se pueden correlacionar, las acciones fallidas desaparecen, la actividad de soporte es invisible o la retención depende de un nivel de plan no documentado.

El traspaso al desarrollador revela dependencias ocultas de la plataforma

El traspaso al desarrollador se aprueba cuando un desarrollador que no creó el piloto puede mantener y publicar la aplicación exportada sin el creador original ni la plataforma. La legibilidad del código importa, pero una transferencia de propiedad satisfactoria es una prueba más sólida.

Entrega al desarrollador receptor un entorno limpio, la exportación del código fuente, notas de arquitectura, referencia de configuración, modelo de datos, historial de migraciones, instrucciones de pruebas, procedimiento de despliegue, procedimiento de recuperación, inventario de dependencias y limitaciones conocidas. Elimina el acceso a la plataforma durante el ejercicio. El creador original puede observar, pero no debe responder preguntas de implementación hasta que se hayan registrado el tiempo y los bloqueos.

Introduce un defecto normal, como un filtro de cliente ausente en una consulta de informes. Pide al desarrollador que lo reproduzca, localice la ruta de autorización, añada una prueba de regresión, repare la consulta, haga un pequeño cambio de esquema, ejecute el conjunto completo de pruebas, despliegue en el entorno de pruebas y explique la vía de reversión. Esta secuencia revela código generado que parece plausible pero carece de límites coherentes o puntos de conexión para pruebas.

Evalúa el traspaso mediante evidencias, no por preferencia de estilo. Registra el tiempo de configuración, las dependencias no documentadas, los comandos fallidos, la propiedad poco clara, la cobertura de pruebas en la ruta modificada, los hallazgos de revisión, el resultado del despliegue y las preguntas que requirieron conocimiento del proveedor. Exige que el desarrollador identifique las áreas generadas que se pueden editar de forma segura y las áreas que la plataforma puede sobrescribir tras cambios posteriores por chat.

Presta mucha atención a la regeneración. Haz una edición convencional de código después de exportar, importa o vuelve a conectar el proyecto si se admite y solicita después un cambio generado por la plataforma en una zona cercana. Determina si la plataforma conserva, reescribe, duplica o entra silenciosamente en conflicto con la edición manual. Los equipos necesitan un modelo operativo declarado para el trabajo mixto entre personas y código generado; «los desarrolladores pueden editar el código» no explica qué ocurre en la siguiente generación.

Suspende el traspaso si la aplicación carece de pruebas repetibles, el modelo de datos existe solo en el historial del chat, los módulos generados no tienen límites estables, los cambios manuales desaparecen o el despliegue sigue requiriendo la cuenta del primer creador. La documentación generada por el mismo sistema puede ayudar, pero el desarrollador receptor debe verificarla frente al código y al entorno de ejecución.

Un traspaso limpio no exige que cada desarrollador admire el estilo generado. Exige que un desarrollador competente pueda prever el impacto de un cambio, probar el comportamiento, revisar rutas sensibles para la seguridad y operar el lanzamiento sin conocimiento privado.

El contrato debe conservar las evidencias que demostraste

El contrato debe avanzar solo cuando se aprueben todos los controles bloqueantes o la empresa acepte formalmente una excepción específica, limitada en el tiempo y con un control compensatorio. Compras debe adjuntar las definiciones de evidencia a la promesa comercial en lugar de basarse en nombres de funcionalidades.

En una evaluación de Koder.ai, somete su exportación de código fuente, despliegue, alojamiento, dominios personalizados, snapshots, reversión, modo planificación y ubicación de la aplicación por país a las mismas reglas de evidencia. El nombre de una funcionalidad invita a probarla, no la demuestra.

Construye el registro de decisión alrededor de siete dictámenes de control. Para cada uno, incluye la revisión probada, el entorno, el responsable de la evidencia, el resultado observado, la ayuda del proveedor, la referencia del defecto, el resultado de la repetición y la consecuencia contractual. Conserva los artefactos sin procesar en almacenamiento controlado por la empresa para que un revisor posterior pueda distinguir lo que observó el equipo de lo que las partes hablaron.

No conviertas un bloqueo sin resolver en un compromiso contractual impreciso de «respaldar» la portabilidad, la residencia o la recuperación. Define el artefacto o comportamiento: una exportación completa de código fuente mediante un proceso establecido, ubicaciones de procesamiento identificadas, campos de auditoría exportables, una vía de restauración probada o acceso continuado a los materiales de compilación necesarios tras la terminación. Establece una solución y un derecho de salida para las afirmaciones que importan para la adopción.

Protege también las condiciones de traspaso. Especifica la propiedad y el uso permitido del código generado, acceso a exportaciones, devolución de datos, comportamiento de eliminación, recuperación de configuración, exportación de auditoría, asistencia de transición y el tratamiento de aplicaciones ya desplegadas cuando termine la relación. Los niveles comerciales pueden diferir, pero el equipo debe saber qué controles probados dependen del nivel seleccionado antes de firmar.

Un aprobado condicional necesita un responsable y una fecha de vencimiento. Vuelve a probar la corrección real en el mismo entorno y actualiza el registro de evidencia original. Una diapositiva que describa una funcionalidad prevista no cierra una prueba fallida, y una demostración en el proyecto preparado del proveedor no demuestra que la corrección se aplique al tuyo.

El piloto ha cumplido su función cuando la decisión sigue clara después de que se desvanezca la emoción de crear. Si el equipo puede exportar, restringir, ubicar, desplegar, recuperar, investigar y traspasar la aplicación bajo su propio control, el contrato se basa en capacidad observada. Si alguna de esas condiciones todavía depende de una explicación, registra el fallo mientras aún resulta barato.