Registro de decisiones de enrutamiento A2P SMS: guía operativa

Qué es un registro de decisiones de enrutamiento y qué problemas resuelve

Un registro de decisiones es una documentación explicativa: deja constancia de por qué se adoptó una decisión de enrutamiento, qué tráfico pretendía cubrir, en qué observaciones se apoyó y quién debe revisarla. No determina por sí mismo cómo se procesa un mensaje.

Resulta útil cuando operaciones, ingeniería, compras y gestión de tráfico necesitan comprender una regla sin reconstruir su historia a partir de conversaciones o cambios de configuración. También permite identificar decisiones provisionales, supuestos pendientes y evidencias que ya podrían no representar las condiciones actuales.

La documentación no demuestra que una ruta vaya a mantener un resultado ni sustituye la verificación de requisitos técnicos, comerciales o regulatorios aplicables.

• Permite responder «por qué existe esta regla» y «a qué alcance se refiere».
• Hace explícitos los límites de la evidencia disponible.
• Ayuda a detectar decisiones sin responsable, fecha de revisión o condición de retirada.

Diferencias entre política ejecutable, historial de cambios y registro de decisiones

La política ejecutable contiene las condiciones que el sistema aplica, como criterios de selección o restricciones definidas por el equipo. Su formato y funcionamiento dependen de cada implementación; no se debe asumir que una plataforma concreta ofrece campos, registros o controles determinados.

El historial de cambios registra modificaciones realizadas en la configuración: qué cambió y cuándo, si esos datos están disponibles. El registro de decisiones explica el razonamiento, el alcance previsto y la evidencia que justificó una decisión. Son documentos relacionados, pero cumplen funciones distintas.

Para evitar divergencias, el registro explicativo debería referenciar la regla o configuración mediante un identificador estable cuando exista, en vez de copiar su lógica completa. Si cambia la política, se actualiza la referencia y se evalúa si la justificación sigue siendo válida.

• Política ejecutable: qué condiciones se aplican.
• Historial de cambios: qué modificaciones se registraron.
• Registro de decisiones: por qué se tomó la decisión y bajo qué condiciones debe reconsiderarse.

Campos mínimos para que una decisión sea comprensible

Use una ficha breve, consistente y fechada. Los campos siguientes son una propuesta de gobernanza documental, no un estándar técnico ni un requisito atribuido a una plataforma.

Defina el alcance con suficiente precisión para que otro equipo pueda distinguir el tráfico cubierto del que queda fuera. Si el alcance depende de destino, tipo de mensaje, remitente u otra condición, anote solo los elementos que correspondan a la decisión y que puedan verificarse.

Registre restricciones y supuestos por separado. Una condición observada en una prueba no equivale automáticamente a una condición garantizada ni a una regla permanente.

• Identificador de decisión y referencia a la regla o configuración relacionada.
• Motivo: problema operativo o necesidad que se busca atender.
• Alcance: tráfico incluido, exclusiones relevantes y contexto observado.
• Restricciones, supuestos y dependencias conocidas.
• Evidencia: fuente, periodo o contexto de observación y limitaciones.
• Responsable de la decisión y equipos consultados, si corresponde.
• Fecha de aprobación o registro, estado y fecha o condición de revisión.

Cómo vincular decisiones con pruebas sin convertirlas en garantías

Describa qué se observó y en qué condiciones: por ejemplo, el tipo de tráfico evaluado, el destino o contexto pertinente, el periodo de observación y la fuente de los datos, siempre que esa información esté disponible y pueda compartirse. Distinga resultados reportados de verificaciones independientes.

En SMS, un acuse de entrega (DLR) es un estado comunicado por la cadena de mensajería; por sí solo no demuestra que el mensaje se haya mostrado o recibido en el terminal. Si la decisión se apoya en DLR, registre qué significa el dato en el sistema que lo produjo y qué incertidumbre permanece.

Use formulaciones acotadas, como «en las condiciones observadas, la prueba registró…». Evite expresiones absolutas sobre entrega, latencia, disponibilidad o rendimiento futuro si no hay evidencia suficiente para sostenerlas.

• Anote el origen y el contexto de cada observación.
• Separe dato observado, interpretación y decisión adoptada.
• Indique límites de muestra, cobertura o verificación cuando se conozcan.
• No convierta un resultado pasado en promesa de comportamiento futuro.

Excepciones, incertidumbre y decisiones provisionales

Si una decisión se toma con información incompleta, indíquelo expresamente. Registre qué se desconoce, qué supuesto permite avanzar y qué dato o condición motivará una nueva evaluación. Esto evita que una excepción provisional se interprete como política general.

Describa las excepciones en términos acotados: motivo, alcance, responsable, duración prevista o evento de revisión y relación con la decisión principal. No incluya datos personales o información sensible que no sean necesarios para entender la justificación.

Cuando exista una condición regulatoria o contractual pertinente, cite la fuente y delimite su aplicación. Por ejemplo, el fragmento disponible de una disposición colombiana menciona restricciones para cierto tráfico A2P relacionadas con numeración E.164, código corto A2P, Sender ID asignado y plantilla de contenido aprobada. Ese fragmento no basta para precisar por sí solo el alcance, la vigencia o la aplicación en otros contextos; consulte el texto completo y la orientación competente antes de tomar una decisión.

• Marque el estado como provisional cuando corresponda.
• Anote incertidumbres y supuestos sin presentarlos como hechos.
• Fije un responsable y un disparador concreto para revisar la excepción.
• Consulte las normas y condiciones aplicables al contexto real.

Flujo de aprobación, revisión y retirada de decisiones

Un flujo auditable puede ser sencillo y ajustarse a la gobernanza de cada organización. Primero, quien propone la decisión describe el problema y delimita el tráfico. Después, las funciones responsables de operación, ingeniería y, cuando corresponda, compras o cumplimiento revisan alcance, evidencia y restricciones.

Antes de aplicar una modificación, contraste la ficha con la política ejecutable y registre la referencia al cambio conforme al proceso interno. Tras la puesta en práctica, documente qué se observó y si la evidencia respalda, limita o contradice la justificación original.

Programe una revisión por fecha o por evento: cambios de condiciones, resultados inesperados, modificación de requisitos o desaparición del problema pueden ser motivos para reevaluar. Si la decisión deja de ser pertinente, márquela como retirada o sustituida y conserve la referencia histórica según las reglas internas. No borre el contexto necesario para explicar decisiones anteriores.

• Propuesta: motivo, alcance y evidencia disponible.
• Revisión: validación por las funciones responsables, según el riesgo y la organización.
• Aplicación: referencia a la política y al cambio correspondiente, si existe.
• Seguimiento: observaciones posteriores con sus límites.
• Revisión o retirada: responsable, fecha o evento y vínculo a la decisión sustituta, si la hay.

Ejemplo hipotético de una ficha de decisión

El siguiente ejemplo es deliberadamente genérico: no describe una ruta, proveedor, cobertura ni resultado comercial real. Sirve para mostrar cómo separar la decisión de la regla ejecutable y de las observaciones que la respaldan.

Identificador: DEC-001. Motivo: evaluar una alternativa de enrutamiento para un tipo de tráfico transaccional autorizado. Alcance: únicamente el segmento definido en la política interna; otros mensajes y destinos quedan fuera. Restricción: aplicar solo tras confirmar los requisitos internos de remitente y contenido. Evidencia: observaciones de pruebas identificadas por su fuente y periodo; no constituyen garantía futura. Responsable: equipo designado por la organización. Estado: provisional. Revisión: al completar la evaluación acordada o si cambian las condiciones que sustentaron la decisión.

La ficha no incluye la condición ejecutable completa. Esa lógica permanece en la configuración controlada por el equipo; la ficha explica el motivo y remite a la referencia correspondiente.

Lista de comprobación para mantener la trazabilidad

Antes de dar por completa una ficha, compruebe que otra persona pueda entender la decisión sin confundir la justificación con la configuración vigente. La documentación debe permitir localizar la evidencia y reconocer sus límites, no prometer resultados.

Evite mantener copias de reglas que puedan quedar desactualizadas. Si una condición ejecutable cambia, revise la ficha relacionada; si la justificación ya no aplica, registre la retirada o sustitución conforme al proceso de la organización.

• ¿La decisión tiene identificador y una referencia localizable a la regla relacionada?
• ¿El motivo y el alcance están descritos con límites claros?
• ¿La evidencia distingue observaciones, interpretaciones y garantías que no pueden afirmarse?
• ¿Se anotaron restricciones, supuestos e incertidumbres?
• ¿Hay un responsable y una fecha o condición de revisión?
• ¿Las excepciones están acotadas y marcadas como provisionales cuando corresponde?
• ¿La ficha evita duplicar la lógica ejecutable y el historial de cambios?
• ¿Se han retirado o sustituido las decisiones obsoletas sin perder la trazabilidad pertinente?