En una página publicada parecen idénticos. Una línea que dice que el contenido se produjo con ayuda de IA, y un registro que muestra qué se produjo, por quién y cuándo. Misma frase, misma ubicación, misma tipografía. La diferencia solo aparece cuando alguien tiene motivo para cuestionarlo, y para entonces ya es tarde para crear el segundo.
Dos cosas que parecen iguales
Una etiqueta es una declaración. Usted describe su propio contenido, con sus palabras, en una superficie que controla. Con arreglo al artículo 50 del Reglamento de IA de la UE es exactamente esa declaración la que se pide, y formularla bien importa.
Un registro es distinto en su naturaleza, no en su grado. Es un objeto creado en un momento concreto, vinculado a un archivo concreto, conservado de modo que ni usted ni quien lo lee pueden revisarlo discretamente. No describe lo que hizo. Lo muestra.
Toda conversación de cumplimiento que acaba mal acaba mal justo en el punto en que alguien confundió lo primero con lo segundo.
Cuánto vale una autodeclaración
Vale algo, y despacharla sería el error contrario. Una divulgación clara, exacta y aplicada de forma coherente es lo que la norma pide. Señala un proceso que funciona. Es lo primero que un cliente razonable quiere ver. Si no la ha hecho, hágala antes de preocuparse por cualquier otra cosa de esta página.
Lo que no es: prueba de sí misma. Una autodeclaración es una afirmación, y una afirmación se sostiene sola solo mientras nadie tenga interés en comprobarla. Suele ser mucho tiempo, y por eso precisamente la brecha pasa inadvertida hasta el día en que importa.
Las tres preguntas que una etiqueta no responde
Ponga cualquier declaración de divulgación junto a estas y la forma de la brecha se hace evidente.
¿Qué se produjo? No lo que hoy está en la página. El objeto exacto que salió. Las páginas se editan. Una declaración escrita hoy sobre una versión revisada dos veces desde entonces describe algo que ya no existe con esa forma.
¿Por quién y con qué? Qué partes se generaron, cuáles editó un modelo, cuáles escribió una persona. Una sola línea al pie de la página comprime todo eso en una palabra, y esa palabra la elige la parte a la que le conviene elegirla.
¿En qué fecha era cierto? Esta es la pregunta que derriba en silencio la mayoría de las respuestas internas. Una declaración hecha en agosto sobre un trabajo de marzo es un recuerdo. Su fecha es la de la redacción de la declaración, no la de la cosa que describe.
Dónde creen los equipos que están sus pruebas
Pida a un equipo de marketing o contenidos que sustente una declaración y salen cuatro cosas, más o menos en este orden. Cada una es útil. Ninguna aguanta cuando se disputa en lugar de consultarse.
Fechas de modificación de archivos. La respuesta más común y la más débil. Una fecha de modificación es un metadato dentro de un sistema que usted administra. Cambia al copiar, sincronizar, exportar o abrir un archivo con la aplicación equivocada, y puede fijarse deliberadamente. Es una nota de trabajo sobre sus propios archivos, no una declaración que otro tenga motivo para aceptar.
Hilos de correo. Mejor, porque interviene una segunda parte que guarda copia. Aun así, débil para este fin. Un correo muestra que algo se habló en una fecha. Rara vez se ancla a una versión concreta del archivo, las cabeceras pueden construirse, y un hilo que a quienes lo vivieron les parece concluyente suele resultar ambiguo a quien no estuvo.
Historial de gestión de proyectos. Transiciones de tickets, comentarios, adjuntos, un registro de auditoría. Parece sólido porque es detallado y lleva marcas de tiempo. El problema es administrativo: los administradores del espacio pueden editar o borrar entradas, las políticas de retención podan discretamente lo antiguo, y todo el almacén pertenece a la parte que hace la afirmación. El detalle no es independencia.
Historial de versiones en la nube. El más sólido de los cuatro y aun así en la misma trampa. El historial muestra una secuencia de estados de un documento. Lo custodia un proveedor con el que usted contrata, bajo condiciones que puede cambiar, en una cuenta que controla, y normalmente caduca. Responde a qué cambió. No responde de forma independiente a cuándo, ante alguien que ha decidido no creerle.
El hilo común no es que estos sistemas sean poco fiables. Es que los cuatro los custodia la parte cuya afirmación está en cuestión. Es un problema estructural, y ninguna cantidad de registro interno adicional lo arregla.
Qué cambia cuando el registro se sella
Sellar mueve una cosa concreta fuera de su control: la fecha.
Se calcula un hash criptográfico a partir del propio archivo, de modo que el registro queda atado a una versión exacta y no a un documento que sigue cambiando. La declaración sobre cómo se produjo el trabajo se une a ese hash. Un prestador cualificado de servicios de confianza emite después un sello de tiempo electrónico cualificado sobre ambos.
Con arreglo al Reglamento eIDAS, Reglamento (UE) n.º 910/2014, un sello de tiempo electrónico cualificado goza de presunción legal respecto de la fecha y la hora que indica y de la integridad de los datos a los que está vinculado. En Suiza, la ZertES regula los servicios de certificación para firmas electrónicas, mientras que la equivalencia con la firma manuscrita procede del art. 14 apdo. 2bis del Código de Obligaciones suizo. Son dos textos distintos y conviene citarlos como dos.
Lo que eso le aporta en la práctica es estrecho y valioso. No hace verdadera su declaración. Hace que la fecha de su declaración sea algo que no pudo cambiar después, y esa es justamente la propiedad que les falta a los cuatro registros internos anteriores. Un hash en un registro público da un resultado parecido pero más débil, por razones que merece la pena leer completas en la comparación con el sellado de tiempo en blockchain.
Un ejemplo desarrollado
Una agencia entrega una campaña en febrero. Página de aterrizaje, seis anuncios, un vídeo de lanzamiento. Parte de los textos se redactó con un modelo, todo lo revisó una persona, una ilustración se generó. La entrega incluye una línea de divulgación, que es más de lo que hicieron casi todas las agencias ese mes.
En agosto adquieren al cliente. El equipo jurídico del comprador realiza una auditoría de contenidos y envía una pregunta: para cada pieza, qué fue generado por IA, qué fue asistido por IA, y qué pruebas sustentan la respuesta. El plazo es de dos semanas y el tono es procedimental, no hostil.
La agencia tiene ahora que reconstruir febrero. El diseñador que generó la ilustración ya no está. El documento se ha editado once veces desde la entrega, la última por el propio cliente. El espacio de gestión de proyectos se migró en mayo y los comentarios de más de noventa días no se trasladaron. Queda un hilo de correo diciendo que la campaña está lista para revisión, y una línea de divulgación de fecha desconocida.
Nada de esto implica mala fe. Cada cual hizo su trabajo. La agencia simplemente no puede responder a una pregunta para la que no tenía motivo de prepararse, y el comprador no es irrazonable al plantearla. El coste son dos semanas de tiempo de perfiles senior, una relación tensa y una respuesta que termina en "hasta donde recordamos".
La versión en la que la agencia selló cada entregable al entregarlo lleva unos diez minutos. Reenvían cuatro certificados. El comprador los verifica sin contactar con nadie. La conversación se acaba.
El punto práctico
Etiquete su contenido. Esa es la obligación y no es opcional. Después hágase una segunda pregunta, que la norma no plantea pero sus clientes acabarán planteando: si alguien que no tiene motivo para confiar en nosotros nos pide sustentar esto dentro de seis meses, ¿qué le entregamos?
Si la respuesta es una carpeta de capturas y un recuerdo, la brecha merece cerrarse mientras sale barato. Nuestra página sobre el artículo 50 expone qué cubre la obligación y dónde encaja una declaración sellada.
