Durante años, «tener un sistema» significó para muchos centros de arbitraje una carpeta compartida bien ordenada, un formulario web para recibir documentos y una cuenta de correo institucional desde la que se notificaba. Funcionaba. Nadie preguntaba.
El numeral 8.2.6 de la Directiva N.º 004-2025-OECE/CD cambió eso. No porque introduzca una tecnología nueva, sino porque convierte en exigible y supervisable algo que antes era criterio de cada institución. Y lo hace con un nivel de detalle inusual: no dice «tenga un sistema informático», dice qué debe registrar ese sistema, con qué fecha, quién debe poder verlo y qué cosas expresamente no cuentan como sistema.
Este artículo recorre el numeral completo. No como abogado —no lo somos— sino como quienes tuvieron que traducir cada literal a una decisión de arquitectura concreta.
La frase que descarta a la mitad del mercado
Empecemos por el final, porque es donde está el golpe. El 8.2.6.14 excluye expresamente de la categoría de «sistema de gestión de expedientes» dos cosas:
- los formularios de carga de documentos, y
- el correo electrónico.
Léalo despacio. Si su mesa de partes es un formulario que recibe archivos y los deja en una carpeta, y sus notificaciones salen de una casilla de correo institucional, la norma ya calificó esa arquitectura: no es un sistema de gestión de expedientes. Da igual lo pulido que esté el formulario.
Esto no es un tecnicismo. Es la diferencia entre poder responder a una supervisión y no poder.
Trazabilidad integral: qué significa realmente
El 8.2.6.1 pide un sistema que registre la trazabilidad de las actuaciones. El 8.2.6.2, el registro cronológico. El 8.2.6.3, cuatro cosas concretas:
- a) fecha y hora automática de ingreso,
- b) fecha y hora verificable de salida y notificación,
- c) identificación cronológica,
- d) consulta del estado del expediente.
El adjetivo del literal a) es el que importa: automática. Si en su sistema el usuario que sube el documento también escribe la fecha en que lo presentó, no tiene fecha automática: tiene una declaración. Y una declaración se puede corregir hacia atrás, que es exactamente lo que la trazabilidad pretende impedir.
La solución correcta es aburrida y contundente: la fecha la pone el servidor, siempre. Cuando un documento llegó en físico y se digitaliza tres días después, no se falsea la fecha de ingreso; se registra la fecha real de recepción como dato del proceso y queda anotado, en el mismo registro, cuándo se cargó al sistema y qué usuario lo declaró. Dos fechas, ambas verdaderas, ninguna reescrita.
El literal b) es más duro de lo que parece, y lo tratamos aparte más abajo.
Mesa de partes y casilla: el 8.2.6.4
Cuatro módulos exigidos, más el soporte:
| Literal | Qué exige |
|---|---|
| a) | Módulo de presentación de solicitudes |
| b) | Mesa de partes virtual |
| c) | Casilla electrónica |
| d) | Seguimiento con verificación de notificaciones |
| e) | Soporte tecnológico y ayuda |
El error más común aquí no es no tenerlos: es tenerlos en sistemas distintos. Una mesa de partes que vive en una aplicación y un expediente que vive en otra generan dos verdades sobre el mismo hecho. Y ahí entra el 8.2.6.9, que exige gestión íntegra sin mecanismos paralelos.
Un centro puede tener los cinco módulos del 8.2.6.4 y aun así incumplir el 8.2.6.9 por tenerlos desconectados. Es el incumplimiento más silencioso de toda la directiva, porque cada pieza, mirada por separado, parece correcta.
El 8.2.6.11: enviar no es notificar
Este es el numeral donde, por nuestra experiencia revisando sistemas, falla prácticamente todo el mercado.
Exige constancia verificable de envío y de recepción. Dos constancias, no una.
Un correo electrónico prueba, con suerte, que un mensaje salió de un servidor. No prueba que llegó a la casilla del destinatario, no prueba cuándo estuvo a su disposición y desde luego no prueba que lo abrió. El acuse de lectura del correo es opcional para el receptor: se apaga con una casilla.
Lo que la norma pide es que el sistema pueda documentar tres momentos distintos:
- Depósito — el centro pone el acto en la casilla del destinatario. Aquí nace la eficacia.
- Puesta a disposición / entrega — el acto está disponible para él.
- Acuse de recepción — el destinatario accedió efectivamente.
Y que cada uno de esos momentos tenga una constancia verificable: firmada, sellada y comprobable después, no un registro en una tabla que alguien con acceso podría editar.
Un detalle que se pasa por alto: la eficacia debe correr desde el depósito, no desde la lectura. Si dependiera de que la parte abra el mensaje, cualquiera podría paralizar un proceso simplemente no entrando a su casilla. Por eso el sistema debe calcular la fecha en que la notificación surte efecto aplicando la regla de días hábiles, y dejarla escrita.
Auditoría: el 8.2.6.6 y el 8.2.6.15
El 8.2.6.6 pide registros de auditoría con usuario, fecha y acción. El 8.2.6.15 pide historial de accesos, modificaciones, incorporaciones y eliminaciones.
Esa última palabra tiene consecuencias técnicas serias. Si su sistema borra físicamente un registro, no puede dejar historial de la eliminación: el rastro se va con el dato. La única arquitectura compatible es la de borrado lógico: nada se elimina, se marca como anulado, con su motivo y su autor.
Y hay una pregunta que casi nadie se hace: ¿quién audita al auditor? Si el registro de auditoría es una tabla más de la base de datos, el administrador del sistema puede editarla. Un registro que el propio administrador puede reescribir no prueba nada frente a un tercero.
Hay dos formas de resolverlo, y conviene aplicar las dos:
- Encadenamiento por hash. Cada evento incorpora el hash del anterior. Alterar un evento del medio obliga a recalcular todos los posteriores; si no se hace, la cadena se rompe y la verificación lo delata.
- Protección en el motor de base de datos. Revocar UPDATE y DELETE sobre esa tabla y añadir un disparador que rechace cualquier intento. Así la inmutabilidad no depende del código de la aplicación —que se puede cambiar— sino del propio motor.
Un aviso técnico para quien vaya a implementarlo: si guarda el contenido del evento en un campo JSON y el motor reordena las claves al almacenarlo, el hash que calcule al releer no coincidirá con el original y su verificación fallará contra registros perfectamente legítimos. Hay que serializar de forma canónica, con las claves ordenadas. Es un detalle pequeño del que depende que toda la prueba funcione.
Perfiles: el 8.2.6.7 y la clave compartida
Exige perfiles diferenciados —parte, árbitro, adjudicador, personal administrativo— y acceso por rol.
La práctica que hay que abandonar es la clave por expediente compartida entre las partes y sus abogados. Es cómoda y sigue siendo frecuente. Y destruye el no repudio: si tres personas usan la misma credencial, ningún acuse de recibo identifica a nadie. El registro dirá que «el expediente 0187» acusó recibo. Eso no es prueba.
Cada parte necesita su propia credencial. Y el personal interno, segundo factor de autenticación: no como buena práctica opcional, sino porque el 8.2.6.12.a exige controles de autenticación y porque una credencial filtrada de secretaría da acceso a todos los expedientes del centro.
Lo que el software no le puede dar
Hay que decirlo con claridad, porque hay proveedores que no lo dicen.
El 8.2.6.12.b exige un sistema de gestión de seguridad de la información certificado bajo ISO/IEC 27001 por un organismo acreditado. Eso es una certificación de la organización, no del software: alcance, política, análisis de riesgos, controles, formación, auditoría interna y auditoría de certificación. Ningún proveedor puede transferírsela con una licencia.
Lo que un buen sistema aporta es la mitad técnica del expediente: control de accesos, segregación de funciones, registro y protección de los eventos, copias de seguridad, gestión de incidentes con evidencia fechada. Cuando llegue el auditor, esos controles no solo están implantados: ya vienen generando evidencia hacia atrás, que es lo que el auditor pide.
El camino completo suele tomar entre 9 y 18 meses. Si su centro está inscrito como de mayor envergadura y aún no lo ha empezado, ese es el punto crítico de su cronograma, no el software.
Lo mismo aplica al 8.2.6.13: la norma exige manuales, videos tutoriales y canal de soporte publicados. La plataforma puede darle la estructura y alojarlos; el contenido, con el criterio y la voz de su centro, lo produce el centro.
Las 24 horas del 8.2.6.16
Comunicar al OECE cualquier incidente de seguridad en un máximo de 24 horas desde que se toma conocimiento.
Este es un requisito que se incumple por descuido, no por mala fe. Alguien detecta un acceso indebido un viernes por la tarde, decide investigarlo el lunes, y para cuando se comunica ya pasaron 68 horas. La consecuencia no es solo el incidente: es la infracción autónoma por no comunicarlo, que la Directiva 012 tipifica por separado.
La defensa es documental. Un registro que anote la fecha y hora de detección, la fecha del reporte y las medidas de cierre convierte una situación incómoda en un expediente de diligencia. Y esa documentación, en un procedimiento sancionador, vale más que cualquier explicación oral.
Por dónde empezar
Si tuviéramos que ordenar el trabajo de un centro que hoy no cumple, sería así:
- Cierre cualquier fuga de acceso a documentos sin autenticación y deje constancia fechada de la corrección. Es la acción de mayor retorno: la subsanación voluntaria antes de la imputación de cargos puede eximir de responsabilidad.
- Confirme con su abogado la fecha de vigencia de las normas y si ya corre algún plazo de adecuación.
- Arranque la ISO/IEC 27001. Es el camino crítico y no depende de usted acortarlo.
- Unifique la mesa de partes dentro del expediente. Es lo que cierra el 8.2.6.9.
- Construya o adopte la casilla con doble constancia. Es lo que cierra el 8.2.6.11, donde casi nadie llega.
Este análisis se elaboró contrastando el texto de la Directiva N.º 004-2025-OECE/CD y normas concordantes. Tiene finalidad informativa y no constituye asesoría legal: la calificación jurídica de cada supuesto y las fechas de vigencia aplicables deben confirmarse con la asesoría de su centro y con la fuente oficial.