En una anulación de laudo, la pregunta que más veces decide el resultado no es de fondo. Es esta: ¿cuándo quedó notificada la parte?
De esa fecha cuelga si el plazo para contestar corrió o no corrió, si el laudo se emitió dentro del término, si una resolución quedó consentida. Y la respuesta tiene que sostenerse sola, sin depender de que el centro diga que sí notificó.
El numeral 8.2.6.11 de la Directiva 004 lo formula sin rodeos: constancia verificable de envío y de recepción. Dos constancias. Este artículo trata de cómo se construyen y por qué la mayoría de implementaciones se queda a mitad de camino.
Tres momentos, no uno
La confusión de origen es tratar «notificar» como un evento único. Son tres, y jurídicamente no valen lo mismo:
1. Depósito. El centro coloca el acto en la casilla del destinatario. Es el momento en que la notificación se perfecciona desde el lado del emisor. Aquí nace la eficacia.
2. Puesta a disposición. El acto está efectivamente disponible para el destinatario en su bandeja.
3. Acuse de recepción. El destinatario accedió: abrió, descargó, acusó.
La distinción no es académica. Si la eficacia dependiera del punto 3, cualquier parte podría congelar un proceso indefinidamente con solo no entrar a su casilla. Por eso la eficacia corre desde el depósito, y el acuse documenta algo distinto: el acceso efectivo, que sirve para acreditar el conocimiento real cuando se discute indefensión.
Un sistema que solo registra «notificado: sí» no puede reconstruir ninguno de los tres. Y uno que hace correr el plazo desde la lectura tiene un problema de diseño con consecuencias procesales.
Qué hace verificable a una constancia
Que un sistema muestre en pantalla «depositado el 12 de agosto a las 17:40» no prueba nada por sí solo. Es un texto en una base de datos que alguien con acceso podría editar.
Para que la constancia sirva frente a un tercero necesita cuatro propiedades:
Fecha del servidor, no del cliente. El reloj lo pone el sistema. Si el navegador del usuario puede influir en la hora registrada, la fecha no es cierta.
Firma criptográfica. El contenido de la constancia —a quién, qué acto, qué expediente, en qué momento— se firma. Cualquier alteración posterior de una coma invalida la firma.
Almacenamiento inmutable. El documento de la constancia se guarda en un repositorio de escritura única, con versionado. Ni un administrador de la plataforma puede sobrescribirlo o borrarlo.
Código verificable. Un identificador corto, legible, que permita a un tercero comprobar la constancia después, sin acceso al sistema. Es lo que convierte un PDF en algo citable en un escrito.
Cuando las cuatro están, la constancia deja de depender de la confianza en el centro. Que es exactamente el objetivo de la norma.
La regla de días hábiles: el detalle que casi nadie implementa
Aquí hay un cálculo que muchos sistemas omiten y que después genera discusiones evitables.
Una notificación depositada un viernes a las 18:30 no surte efecto ese viernes a las 18:30. Depende de la regla de eficacia aplicable —horario de atención, días hábiles, feriados—. Y ese cálculo tiene que hacerlo el sistema, en el momento del depósito, y dejarlo escrito.
No basta con que el reglamento del centro diga cómo se cuenta. Si la fecha en que la notificación surte efecto se calcula a mano, meses después, cuando alguien la necesita para un escrito, no es una fecha cierta: es una interpretación.
Un sistema correcto muestra, en la propia constancia, dos fechas separadas:
- Depositada: 05/08/2026, 05:24
- Surte efecto: 05/08/2026, 08:00
Y esa segunda fecha se calculó sola, con la regla vigente, en el instante del depósito.
Credencial propia por parte: sin esto el acuse no vale
Un problema que arrastra buena parte del mercado: una clave por expediente, compartida entre la parte, su abogado y quien haga falta.
Es cómodo. Y destruye el valor probatorio del acuse.
Si tres personas usan la misma credencial, el registro dirá que «el expediente 0187» acusó recibo. ¿Quién accedió? No se sabe. ¿Puede la parte alegar que ella nunca entró, que fue un tercero con la clave? Puede, y no hay forma de rebatirlo.
El 8.2.6.7 exige perfiles diferenciados por parte, árbitro, adjudicador y personal. La razón de fondo es el no repudio: sin identidad individual, ningún acto de la parte dentro del sistema se le puede atribuir con firmeza.
Dar credencial propia a cada parte tiene un coste operativo pequeño —un alta cuando se admite la solicitud— y cambia por completo lo que el sistema puede probar.
El adjunto también tiene que probarse
La constancia acredita el acto de notificar. Falta acreditar qué se notificó.
De cada documento adjunto debe guardarse su huella digital —su hash— en la base de datos, separada del archivo. Así, si mañana alguien discute que el PDF notificado no es el mismo que consta en el expediente, el contraste es aritmético: se recalcula el hash del archivo y se compara con el valor almacenado. Coinciden o no coinciden. No hay zona gris.
Una lista para revisar su sistema actual
Pruebe estas seis preguntas contra lo que hoy tiene:
- ¿Puede emitir una constancia de depósito distinta de la de recepción?
- ¿La fecha en que la notificación surte efecto la calculó el sistema, o se calcula a mano?
- ¿La constancia está firmada, de modo que una edición posterior sea detectable?
- ¿Está guardada en un repositorio donde el administrador tampoco pueda borrarla?
- ¿Cada parte tiene su propia credencial, o comparten una clave por expediente?
- Si dentro de dos años se discute qué documento se notificó, ¿puede probarlo con un hash?
Si alguna respuesta es incómoda, ese es exactamente el punto que un supervisor —o la contraparte en una anulación— va a encontrar.
Contenido informativo elaborado sobre el texto de la Directiva N.º 004-2025-OECE/CD. No constituye asesoría legal ni sustituye el criterio del área legal de cada centro.