Decisiones verbales en IT: cómo documentar para no acabar siendo el culpable

El patrón que destruye a los responsables de IT en pymes

Llega una petición urgente. Sin ticket, sin email, sin nada. Tu director te dice en el pasillo que pares el proyecto A y te pongas con el proyecto B. Un mes después, el proyecto A es de repente crítico y tú eres el que no lo priorizó. Él no recuerda haber dicho nada. Tú tampoco puedes demostrarlo.

Este ciclo tiene un nombre: ausencia de trazabilidad. Y en una pyme donde el responsable de IT es una sola persona, la ausencia de trazabilidad no es un detalle organizativo menor — es un riesgo corporativo real y una trampa personal muy concreta.

La comunidad técnica que ha vivido esta situación tiene una postura clara: el problema no es la mala fe de los directivos necesariamente, sino la ausencia de procesos. Y la solución tampoco es confrontar ni victimizarse — es construir una arquitectura defensiva de documentación que funcione incluso cuando la cultura de la empresa resiste activamente.

Por qué documentar no es burocracia: es defensa legal y operativa

Bajo marcos como ITIL o ISO 20000, cualquier cambio en sistemas, accesos o configuraciones debería tener un registro. El RGPD va más lejos: si hay una decisión sobre datos personales — quién accede, qué se elimina, qué se conserva — esa decisión debe ser trazable. Si no lo es, la empresa está expuesta. Y si la empresa está expuesta y no hay registro de quién decidió qué, el técnico de IT es el único que aparece en el organigrama como responsable.

Dicho de otra forma: la falta de trazabilidad no es un fallo tuyo, es un fallo de gobernanza de la organización. Pero en un conflicto real, eso no te protege automáticamente. Lo que te protege es el registro escrito.

Además, hay un argumento de negocio que no debería ignorarse: los proyectos que se cancelan sin explicación, el trabajo duplicado, los malentendidos que obligan a rehacer implementaciones — todo eso tiene un coste en horas y en dinero. Documentar bien no ralentiza la operación, la estabiliza.

La táctica del email de confirmación inmediato

La herramienta más efectiva que circula entre profesionales de IT en esta situación es simple y no requiere que la empresa cambie ningún proceso: el email de confirmación enviado justo después de cualquier decisión verbal.

El formato es directo. Algo como: 'Según nuestra conversación de hoy a las 15:15, me has indicado que pause el trabajo en el proyecto A y me centre en el proyecto B. Confirmo que así lo haré. Si hay algún cambio, avísame.'

Lo que ocurre a partir de ahí tiene solo dos salidas, y las dos te convienen:

• No responden: el email queda en tu bandeja enviada con fecha y hora. Si más adelante alguien dice que esa decisión nunca se tomó, tienes el registro. La ausencia de refutación en un plazo razonable convierte ese email en el documento oficial de esa conversación.
• Responden corrigiendo algo: perfecto, acabas de obtener la decisión real por escrito. Si esa corrección también llega de forma verbal, vuelves a enviar otro email de confirmación. El proceso se repite hasta que algo quede escrito.

Si alguien se queja de que envías demasiados emails, la respuesta es tranquila y profesional: 'Solo quería confirmar que lo había entendido bien para no malgastar tiempo en la dirección equivocada.' Es difícil objetar eso sin quedar mal.

Cuando el directivo es quien viola el proceso

El escenario más complicado es cuando quien no documenta no es un compañero, sino tu gestor directo — la persona que tiene poder sobre tu continuidad en la empresa. Aquí la confrontación directa suele ser contraproducente. Lo que funciona son dos enfoques complementarios.

El primero es lo que algunos profesionales llaman la postura de mala memoria: en lugar de pedir documentación explícitamente, simplemente dices que necesitas que te lo confirmen por escrito porque si no, se te olvidará. Esto funciona especialmente con gestores que disfrutan de una posición de superioridad, porque el mensaje que reciben no es 'necesito que te justifiques' sino 'necesito tu ayuda para no cometer errores'. El resultado es el mismo — una instrucción escrita — pero sin la resistencia emocional.

El segundo es el sistema de tickets como política de trabajo, no como sugerencia. Si la empresa ya tiene algún sistema de gestión de tareas — da igual si es Jira, Asana, un formulario de email o incluso una hoja compartida — puedes establecer de forma profesional que es ahí donde registras y priorizas el trabajo. 'Trabajo mejor cuando tengo las prioridades centralizadas en el sistema, así nada se pierde.' Es una frase que no acusa a nadie y, al mismo tiempo, ancla el proceso.

Implementar tickets cuando la cultura resiste la formalización

Pedir a una organización acostumbrada a funcionar por pasillo y teléfono que abra tickets para todo genera rechazo casi garantizado. La clave no es imponer el cambio de golpe, sino hacerlo inevitable de forma gradual.

Algunas formas que funcionan en la práctica:

• Reduce la fricción al mínimo posible: si abrir un ticket requiere diez campos obligatorios, nadie lo hará. Un formulario con tres campos — quién pide, qué se necesita, para cuándo — ya es suficiente para crear trazabilidad.
• Convierte el ticket en condición silenciosa: cuando alguien te pide algo verbalmente, abre tú el ticket mientras lo escuchas y dile que lo has registrado para que no se pierda. Estás haciendo el trabajo por ellos, pero el registro existe.
• Usa el backlog como argumento: cuando hay conflicto de prioridades — que siempre lo hay — el sistema de tickets permite mostrar objetivamente qué estaba en cola y en qué orden llegó. Eso neutraliza el 'yo lo pedí antes' sin discusión.

Lo importante es que el sistema de tickets deje de ser una herramienta de IT para convertirse en el lugar donde la empresa registra sus decisiones operativas. Cuando eso ocurre, su valor es evidente para todos, no solo para el técnico.

Protegerse si decides marcharte: el paper trail defensivo

Si ya tienes claro que vas a salir, la prioridad cambia ligeramente. Ya no se trata solo de mejorar los procesos — se trata de asegurarte de que cuando te vayas, nadie pueda atribuirte responsabilidades que no son tuyas.

Esto requiere lo que se puede llamar un paper trail defensivo: un archivo personal y ordenado de comunicaciones, emails enviados, confirmaciones de decisiones, registros de tickets cerrados y documentación de lo que estaba en marcha cuando llegaste y cómo estaba cuando te vas.

• Guarda copias de los emails relevantes fuera del sistema de la empresa — en una cuenta personal, en un documento privado, donde puedas acceder si dejan de darte acceso al correo corporativo el día que sales.
• Documenta el estado actual de cada sistema crítico: versiones, configuraciones, contratos de soporte con el MSP, credenciales en un gestor de contraseñas con traspaso formal.
• Si hubo decisiones explícitas del tipo 'eso no es necesario, yo me encargo' que luego generaron incidentes, esos emails de confirmación enviados en su momento son tu defensa. Si no los tienes, es tarde para crearlos retroactivamente — pero no para los que ocurran de aquí en adelante.

Conviene también conocer el marco laboral que aplica. La legislación laboral protege al trabajador frente a decisiones arbitrarias, especialmente cuando se puede demostrar que el empleado actuó de buena fe siguiendo instrucciones recibidas. Un despido o una sanción derivada de no haber ejecutado una decisión que nunca quedó formalizada tiene un recorrido complicado para la empresa — siempre que el trabajador pueda demostrar que intentó documentar y fue ignorado o rechazado.

El problema de fondo: la gobernanza IT no es opcional

Todo lo anterior son tácticas de supervivencia. Pero la lectura de fondo es más estructural: una pyme que toma decisiones IT de forma verbal, cancela proyectos sin registro y culpa al técnico de fallos organizacionales no solo crea un entorno de trabajo insostenible — está incumpliendo obligaciones de gobernanza que aplican independientemente de su tamaño.

Cuando ocurre un incidente — una caída de sistema, un acceso indebido, una pérdida de datos — la pregunta que hacen los auditores, los clientes o la autoridad de control no es quién es el responsable de IT. La pregunta es si hay un registro de quién tomó cada decisión y cuándo. Si no lo hay, la empresa no puede defenderse, y el técnico tampoco.

Implementar un proceso mínimo de change management no requiere ni certificaciones ni software caro. Requiere voluntad de registrar. Y si esa voluntad no existe en la organización, el técnico de IT puede — y debe — construir su propio registro unilateral. No como acto de desconfianza, sino como práctica profesional básica.

Si gestionas IT en solitario y reconoces alguno de estos patrones en tu día a día, merece la pena preguntarse: si mañana hay un incidente, ¿puedo demostrar qué se decidió, quién lo decidió y cuándo? Si la respuesta es no, el momento de empezar a documentar es ahora — no cuando el problema ya haya llegado.