Una excepción temporal puede ayudar a que una organización avance más rápido. Pero alguien todavía tiene que decidir cuándo debe terminar.

En una organización anterior, participé en la decisión de adelantar el lanzamiento de un producto digital. Modificamos parte del proceso habitual de entrega y aceptamos los trade-offs correspondientes. En ese momento, poner el producto en marcha y aprender de él era lo prioritario.

Años después, en otra organización, encontré una forma de trabajar que surgió de decisiones similares tomadas antes de que yo llegara. Podía ver cómo funcionaba, pero no era fácil averiguar por qué se había estructurado de esa manera. Conocí el propósito original y los trade-offs al conversar con algunas de las personas que habían participado.

Esa historia existía. Simplemente no estaba disponible sin esas conversaciones.

Eran decisiones distintas en organizaciones distintas. Pero me dejaron la misma pregunta: si las personas que aprobaron una excepción siguen su camino, ¿quién puede explicar por qué la organización todavía convive con ella?

Cuando la IA ayuda a los equipos a avanzar más rápido, tienen más oportunidades de probar y aprender. También pueden poner en marcha más decisiones de las que la organización puede revisar con criterio.

Una excepción temporal necesita una segunda decisión.

Un lanzamiento exitoso no resuelve el trade-off

Hacer una excepción puede ser una decisión responsable. Un equipo puede necesitar un camino distinto para un producto en etapa temprana, siempre que las personas involucradas entiendan qué cambia, qué riesgos asumen y qué salvaguardas siguen vigentes.

Cuando el producto entra en producción, todos ven lo que el equipo entregó. El lanzamiento puede incluso mostrar que valió la pena hacer la apuesta inicial. Pero eso todavía no nos dice si la excepción debe continuar una vez que el producto crece, el equipo cambia o la urgencia original desaparece.

La dificultad aparece después. Otras personas construyen sobre el producto, le dan soporte y asumen nuevos compromisos en torno a él.

El equipo que sabía qué restricciones eran temporales puede ya no estar a cargo. El siguiente equipo hereda una forma de operar sin saber necesariamente por qué se estableció.

En el costo institucional de la autoridad tecnológica paralela, describí lo que puede ocurrir cuando una excepción orientada a la velocidad se convierte en una estructura permanente. La pregunta aquí es anterior: ¿cómo sabrá el siguiente líder que esa excepción existe—y si tiene sentido mantenerla?

En aquella segunda organización, esas conversaciones fueron valiosas: me dieron una historia que yo no tenía. Pero una organización no debería tener que buscar a las personas adecuadas años después para explicar una excepción con la que todavía convive.

El lanzamiento puede ser un éxito mientras el motivo de la excepción pierde vigencia. La organización necesita una forma de advertir esa diferencia.

Mantener juntos el motivo y el punto de revisión

Como arquitecto, he utilizado Architecture Decision Records (ADR) para registrar el razonamiento detrás de las decisiones técnicas. Extendería esa misma práctica a las excepciones significativas de negocio y tecnología. El formato puede ser simple; lo importante es que el siguiente responsable pueda encontrar la respuesta a estas preguntas:

• ¿Qué buscábamos lograr y por qué necesitábamos una excepción en ese momento?
• ¿Qué cambió en el proceso habitual y qué salvaguardas se mantuvieron?
• ¿Qué trade-off aceptamos y quién asumió la responsabilidad?
• ¿Cuándo volveremos a evaluar la decisión y qué evidencia nos llevaría a renovar, modificar o finalizar la excepción?

Las respuestas pueden estar repartidas entre una aprobación de negocio, un registro técnico y una evaluación de riesgos. Alguien todavía tiene que conectarlas. Un documento de arquitectura por sí solo no explica el criterio de negocio; un objetivo de negocio por sí solo no explica las consecuencias operativas.

Esto no requiere un documento complejo ni el mismo proceso para cada decisión. Un experimento breve y de bajo riesgo puede necesitar solo un registro conciso y un punto de revisión claro.

En cambio, una decisión que altera responsabilidades operativas o expone a la organización a un riesgo duradero exige más evidencia y la participación de más personas. El criterio decisivo es si el siguiente responsable puede entenderla y reconsiderarla sin tener que reconstruir toda la historia.

Tomemos un ejemplo ilustrativo, no un caso real de ninguna de las dos organizaciones. Un equipo utiliza un esquema de entrega temporal para un piloto de producto de seis meses. Los requisitos obligatorios de seguridad y las exigencias legales siguen aplicando, pero la integración y el soporte a largo plazo requerirán una decisión formal si el piloto continúa.

Un registro breve podría indicar por qué se permite ese camino excepcional para el piloto, quién responde por los resultados y qué deben revisar los líderes de negocio, tecnología y riesgos antes de que el producto se expanda.

Seis meses después, decir «ya lanzamos» no es suficiente. Los líderes deben analizar qué hicieron los clientes, cuánto cuesta operar el producto y qué trabajo queda pendiente.

Entonces pueden dar por cerrado el piloto, renovar la excepción con una justificación explícita, o trasladar el producto a un modelo operativo que pueda sostenerlo. Si deciden renovarla, deben justificar por qué ese mismo trade-off sigue siendo aceptable hoy.

Una fecha de revisión solo importa si alguien toma la siguiente decisión. No hace falta registrar cada decisión rutinaria. Pero si nadie asume la revisión de una excepción relevante, el registro simplemente se quedará ahí.

Usar la IA para recuperar contexto, no para inventarlo

Estoy trabajando en la creación de startups AI-native con este problema en mente. Busco que la IA nos ayude tanto en la entrega de tecnología como en la forma en que curamos el conocimiento y las decisiones de la organización. Es una dirección hacia la que avanzo, no un sistema probado.

La IA podría ayudar a un equipo a redactar un registro a partir de notas aprobadas, encontrar decisiones relacionadas, señalar lo que falta y recordarle al responsable cuándo corresponde una revisión. Podría hacer que el contexto sea más fácil de recuperar.

Lo que no puede hacer es saber por qué alguien aceptó un riesgo si ese motivo nunca se registró. Un resumen convincente no sustituye revisar la fuente ni hablar con las personas involucradas.

No he probado esto como una práctica a nivel de toda la empresa ni he medido su efecto en la deuda técnica, la seguridad o el ritmo de entrega. Lo que sí experimenté fue la diferencia entre saber cómo funciona un esquema de trabajo y ser capaz de explicar por qué fue elegido.

He escrito sobre cómo las empresas AI-native aún pueden heredar organizaciones del pasado. No quiero construir una que dependa de que unas pocas personas recuerden por qué las cosas funcionan como funcionan.

El límite es claro: la IA puede ayudar a preservar y hacer visible el contexto. Los líderes de negocio y tecnología todavía tienen que explicitar el trade-off, asumir el riesgo dentro de sus responsabilidades y tomar la siguiente decisión cuando las circunstancias cambien.

Quiero usar la IA donde nos ayude a avanzar más rápido. También quiero que quienes vengan después de nosotros entiendan por qué tomamos las decisiones que van a heredar.

Si las personas que aprobaron una excepción se fueran mañana, ¿podría el siguiente líder descubrir por qué se permitió, quién aceptó el trade-off y cuándo debe reevaluarse?