Separación de funciones: cómo el software protege contra el fraude

En la transferencia custody, el control no consiste en esconder un botón ni en pedir una firma más. Consiste en garantizar, por diseño, que quien mide un tanque no pueda facturarse a sí mismo el resultado. Esa garantía no es un detalle de comodidad: es la diferencia entre una cifra que resiste una auditoría y una cifra que solo resiste hasta la primera pregunta incómoda.

Cuando una sola persona puede capturar el dato, aprobarlo y emitir el ticket, el sistema le está pidiendo que se vigile a sí misma. Funciona mientras todos actúan de buena fe y nadie comete un error. El problema es que el control interno no se diseña para los días buenos; se diseña para el día en que algo —un descuido, una presión, una tentación— rompe la cadena. Este artículo explica cómo TankOS convierte la separación de funciones en una propiedad estructural del producto, no en una promesa de procedimiento.

Qué es la separación de funciones (SoD)

La separación de funciones, conocida en auditoría como segregation of duties o SoD, es un principio antiguo y muy sencillo de enunciar: las tareas sensibles de un proceso se reparten entre manos distintas, de modo que ninguna persona controle el ciclo completo de una operación de valor.

En custody transfer, ese ciclo tiene al menos tres momentos críticos que nunca deberían vivir en la misma mano:

• Capturar el dato. Quien va al patio, lee la cinta de aforo, registra la temperatura y documenta el agua libre.
• Aprobar el dato. Quien revisa que la captura sea coherente, completa y conforme antes de que adquiera valor oficial.
• Emitir el ticket. Quien convierte el dato gobernado en un documento fiscal con efectos comerciales.

Cuando estos tres roles son personas distintas, el proceso se autovigila: cada eslabón es revisado por otro eslabón con intereses no alineados. Esa es la esencia del control. No depende de la honestidad individual; depende del reparto.

Quien mide no se factura a sí mismo.

El principio "quien mide no aprueba"

Concentrar funciones en una sola mano es cómodo y rápido. También es exactamente la condición que toda metodología de auditoría señala como factor de riesgo número uno. Cuando una persona captura, aprueba y emite, dos cosas se vuelven posibles, y la segunda es peor que la primera.

La primera es el error no detectado. Una lectura mal transcrita, una temperatura confundida, un agua libre olvidada. Sin una segunda mano que apruebe, el error viaja sin fricción hasta el ticket y de ahí a la factura. Nadie lo cometió con mala intención, pero el daño económico es idéntico al del fraude.

La segunda es el fraude estructural. No hablamos de acusar a nadie: hablamos de que el diseño permita inflar o tapar una cifra sin que el sistema lo note. Un volumen alterado en la captura, una aprobación que el mismo capturador se concede, un ticket emitido sobre un dato que nunca fue revisado por un tercero. Donde el control existe solo en la cabeza de las personas, el fraude depende de la voluntad de no cometerlo. Donde el control es estructural, el fraude requiere coludir a varias personas con intereses distintos, que es justamente lo que la SoD encarece deliberadamente.

Muchas suites OEM cerradas típicas controlan estos pasos solo por interfaz: ocultan o muestran botones según el perfil de quien entró. Eso ayuda, pero no basta. Si la regla vive únicamente en la pantalla, un atajo —una llamada directa, una sesión técnica, una integración mal configurada— puede saltársela sin dejar rastro. La separación de funciones que de verdad protege tiene que vivir más abajo que el botón.

Forzada en dos capas

En TankOS la separación de funciones se valida en dos capas independientes, y esa redundancia es deliberada.

La primera capa es la del servidor de aplicación. Cada acción sensible —capturar, aprobar, emitir— se autoriza contra el rol de quien la solicita, sin importar desde dónde llegue la petición. No depende de que la pantalla haya ocultado un botón; depende de que la operación misma sea rechazada si el rol no corresponde. Aunque alguien construyera una petición a mano, la regla se aplica igual.

La segunda capa es la de la base de datos. Las reglas de incompatibilidad entre funciones están grabadas como restricciones del propio almacén de datos: siete pares de funciones separadas que el sistema se niega a violar incluso si una capa superior fallara. Si por un defecto, una mala integración o una manipulación la lógica de aplicación dejara pasar algo indebido, la base de datos lo detiene. Es el cinturón y los tirantes del control interno.

¿Por qué importa la doble capa? Porque un control de una sola capa tiene un único punto de falla. Quien quiera vulnerarlo solo necesita encontrar la grieta de esa capa. Con dos capas independientes, vulnerar el control exige romper ambas a la vez —algo mucho más difícil, mucho más visible y, sobre todo, mucho más caro de intentar. La defensa en profundidad no es paranoia; es el estándar que cualquier auditor espera encontrar en un proceso de valor fiscal.

El laboratorio como ejemplo

El laboratorio ilustra el principio con claridad. Quien carga la muestra y registra el resultado de un ensayo no es quien lo aprueba. La aprobación es, por construcción, de otra mano. El analista propone; un segundo rol dispone. Hasta que esa segunda mano no valida, el resultado existe pero no es oficial: es un dato crudo, no un dato gobernado.

Esto tiene una consecuencia práctica importante. El resultado de laboratorio no se "cuela" en un cálculo o en un ticket por el solo hecho de haberse tecleado. Necesita pasar por la mano que aprueba. Y como esa aprobación queda registrada —quién, cuándo, sobre qué dato—, cualquier revisión posterior puede reconstruir la cadena completa. El mismo patrón rige la captura de aforo y la emisión del ticket custody: medir, aprobar y emitir son siempre manos distintas, y el sistema se asegura de que así sea.

Conviene recordar aquí la doctrina que ordena todo el sistema. El aforo de cinta es la medición fiscal; la telemetría de radar es información operativa y no la sustituye. TankOS no toca el aforo: lo digitaliza, lo registra y lo fortalece, volviéndolo auditable, trazable e inalterable. Y no se factura sobre un radar caído. La separación de funciones se aplica sobre el dato fiscal correcto, capturado por el método correcto, para que el control no proteja una cifra que no debería existir.

Qué gana la operación

El resultado de todo esto se resume en una frase: una cifra que resiste auditoría porque ningún punto único pudo inflarla ni taparla.

• Trazabilidad completa. Cada paso —captura, aprobación, emisión— queda atribuido a una mano y a un momento, con un registro de auditoría conservado durante siete años.
• Imposibilidad estructural del punto único. Ninguna persona controla el ciclo entero. Para alterar una cifra haría falta romper la separación en dos capas a la vez y coordinar a varios roles.
• De dato crudo a dato gobernado. El número que llega al ticket no es lo que alguien tecleó: es lo que el proceso revisó, aprobó y selló.
• Conformidad sin fricción. El control no es un trámite añadido sobre el trabajo; es la forma en que el trabajo ocurre.

Para una gerencia, una auditoría o un área de cumplimiento, esto cambia la conversación. La pregunta deja de ser "¿confiamos en quien capturó?" y pasa a ser "¿el sistema permitió siquiera que una sola mano lo manipulara?". La respuesta, por diseño, es no.

Conclusión

La separación de funciones no es una casilla de cumplimiento ni un gesto de cortesía hacia el auditor. Es el mecanismo que hace que una cifra de custodia signifique algo. En TankOS ese mecanismo no vive en una pantalla: vive en el servidor y en la base de datos, en siete pares de funciones separadas que el sistema se niega a violar. Quien mide no aprueba, quien aprueba no se factura, y cada paso queda registrado para quien tenga que revisarlo años después.