Informe verificable

Un resumen generado por IA te pide una cosa incómoda: que te fíes. No sabes si esa frase estaba de verdad en la reunión, quién la dijo ni en qué momento. El informe verificable de Uttera cambia eso: en vez de un texto que hay que creerse, produce un informe que se puede comprobar frase a frase. Es nuestro servicio más distintivo.

La idea es sencilla y deliberada: no decidimos nosotros qué es verdad —eso lo juzga quien escucha—. Lo que hacemos es anclar cada afirmación a la grabación: la sacamos con su cita literal, el hablante, el segmento y el minuto exacto, y marcamos si esa cita está palabra por palabra en el audio. Tú pones el juicio; nosotros ponemos de dónde sale cada frase, de forma que no se pueda discutir.

Para qué sirve

Cualquier situación en la que lo que se dijo importa y, más tarde, alguien puede ponerlo en duda:

• Actas de consejo y de junta — lo acordado queda anclado a quién lo dijo y cuándo.
• Peritaje y litigio — una grabación convertida en prueba que la otra parte puede comprobar por su cuenta.
• Compliance y auditoría — declaraciones y controles con su respaldo literal.
• Due diligence — lo que se afirmó en las reuniones, trazable frase a frase.
• Procedimientos de RR. HH. — entrevistas y comparecencias con constancia verificable.
• Periodismo — citas ancladas al minuto exacto de la fuente.
• Disputas con clientes o proveedores — «esto quedó dicho» deja de ser tu palabra contra la suya.

Conviene tener claro, desde el principio, qué prueba Uttera de tu informe —y qué no—:

El grafo de evidencia

El análisis se entrega como un grafo de evidencia (evidence_graph): una lista de claims, las afirmaciones relevantes de la grabación. Cada una lleva text, state (su estado: dicho, condicional, en disputa… — la lista completa, más abajo), speakers, entities, posibles depends_on (de qué otra afirmación depende) y un array evidence con los tramos que la respaldan (segment_id, t_start/t_end, quote y grounding).

Cada afirmación se clasifica en dos ejes, para que de un vistazo sepas qué es y cuánto pesa.

Qué es — el tipo:

• Decisión — algo que se decidió.
• Compromiso — algo a lo que alguien se comprometió, con su responsable y, si lo hay, su plazo.
• Cifra — un número: un importe, un plazo, una cantidad, un porcentaje.
• Riesgo — un riesgo que se señaló.
• Pregunta — una pregunta que quedó en el aire.
• Contradicción — dos cosas dichas que no casan entre sí.
• Afirmación — cualquier otra afirmación relevante.

Cuánto pesa — el estado:

• Dicho — se afirmó de forma explícita.
• Condicional — depende de una condición, que el grafo indica aparte.
• Inferido — se deduce de lo hablado; no se ancla como verificado.
• En disputa — los presentes no están de acuerdo.
• Sin resolver — quedó abierto, sin cerrar.

Ese grounding es el anclaje de cada cita, y lo decimos sin adornos:

🔴 Anclar no es juzgar la verdad. El grafo dice quién dijo qué y dónde, y que esa cita está de verdad en el audio. No dice que lo dicho sea cierto: eso —y la exactitud de la transcripción— lo decide quien escucha. Es la misma distinción de Verificar: autenticidad y anclaje no son veracidad.

Las cifras del informe cuadran con lo que se dijo

Un acta vale por sus números: un importe, un plazo, un porcentaje, una cantidad. Por eso, cuando una afirmación lleva una cifra, el informe la contrasta con la cita literal de la que sale. Si el número del informe no aparece en lo que se dijo, se señala —no se deja pasar como si estuviera respaldado—.

Dos niveles de verificación

No todos los informes necesitan el mismo rigor. Por eso hay dos niveles:

Forense: disponible próximamente para los planes superiores.

Cómo pedirlo

Por la API, es el servicio de resumen con ?mode=intelligence (y, si quieres fijar el tipo de informe, report_schema/report_prompt). Añade ?report=pdf para el PDF firmado: el grafo ya validado va dentro del documento, cubierto por su firma, así que el PDF se basta solo para comprobarlo. El PDF llega en report.pdf_base64 con sus firmas (content_signature, container_signature, pdf_sha256, key_fingerprint). El cobro es por tokens, como el resumen; una afirmación unverified no se cobra aparte ni se vende como verificada.

curl -X POST "https://api.uttera.ai/v1/summarize?mode=intelligence&report=pdf" \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -F "file=@reunion.mp3" \
  | jq -r '.report.pdf_base64' | base64 -d > informe.pdf

Sin programar, en el Estudio: marca la casilla «Informe verificable», elige el idioma de salida y ejecuta; el grafo se pinta en pantalla y puedes descargarlo (JSON) junto al PDF.

Verificar un informe

Cada informe en PDF que emitimos va firmado criptográficamente. Cualquiera —tú, tu cliente, la otra parte de una negociación— puede comprobar que un informe salió de nosotros y que nadie lo ha tocado por el camino, sin pedirnos permiso y sin tener cuenta.

Lo más rápido es la página. En uttera.ai/verificar se sube el PDF y ya está: no hay nada que copiar ni que pegar, porque la firma viaja dentro del propio fichero. Sirve para quien recibe un informe y no va a escribir código —un abogado, un perito, la otra parte—. El resto de este capítulo es para hacerlo por tu cuenta, con curl o sin pasar por nosotros.

🔴 Autenticidad no es veracidad. Verificar un informe dice de dónde viene el documento y que nadie lo ha modificado. No dice que lo que cuenta sea cierto. El informe se genera a partir de una grabación que aporta el cliente, y tanto la exactitud de la transcripción como la veracidad de lo que en ella se dice son responsabilidad suya. Uttera no presencia lo grabado, no lo comprueba y no lo certifica.

Qué es y qué no es. Es una firma criptográfica de autenticidad con Ed25519. No es una firma electrónica cualificada en el sentido del reglamento eIDAS: prueba que el documento salió de nuestro sistema y que no ha cambiado, no equivale a un certificado de un prestador cualificado. Lo decimos aquí y lo dice el propio informe.

Por qué son dos firmas

Cada informe lleva dos, y cada una responde a una pregunta distinta:

La de contenido va impresa dentro del informe, al pie de cada página, en forma de huella corta. La de contenedor no puede ir dentro —firmar algo que luego se modifica es imposible— así que se añade detrás del documento ya terminado, en una línea al final del fichero que empieza por %%UTTERA-FIRMA-V1:. Un lector de PDF no la ve: el formato manda leer desde el último startxref, así que lo que va después del %%EOF lo ignora.

Esto es lo que permite que baste con el PDF para comprobar las dos firmas. Antes la devolvía la API aparte y había que guardarla al lado del fichero: en cuanto alguien reenviaba el informe por correo, la firma se quedaba atrás y el documento era imposible de verificar. La API la sigue devolviendo en report.container_signature para quien prefiera archivarla por separado.

Sello de tiempo de un tercero (RFC 3161)

Las dos firmas dicen quién y qué. El cuándo lo añade un tercero independiente: cada informe pide, en el momento de emitirse, un sello de tiempo RFC 3161 a una autoridad de sellado externa (una TSA) sobre la huella de su firma de contenido. La TSA devuelve un comprobante firmado por ella que dice «esta huella existía a esta hora», y ese comprobante viaja dentro del propio PDF, junto a las firmas.

¿Por qué importa? Sin esto, la hora del informe la ponía nuestro reloj, dentro de lo que firmamos nosotros mismos: tendrías que fiarte de que no la hemos retrasado. Con el sello RFC 3161 la fecha la atestigua alguien que no somos nosotros y que no tiene nada que ganar. Es lo que un perito o un juzgado esperan para fijar cuándo existió un documento.

En el pie del PDF, bajo la firma, aparece la línea «Sello de tiempo (RFC 3161): … UTC · <autoridad>». Al verificar el informe —en la página o por la API— se comprueba que el sello sea sobre ese contenido y se devuelve la hora atestiguada en los campos timestamp_present, timestamp_valid, timestamp_unix y tsa.

Puede no estar. El sello es un extra, no un requisito: si la autoridad externa no responde en el momento de emitir, el informe sale igual con sus dos firmas y sin sello, y la verificación lo indica como sin sello externo (no como inválido). Los informes anteriores a esta función tampoco lo llevan. Y, como la firma Ed25519, no es una firma electrónica cualificada eIDAS: es un sello de tiempo de un prestador reconocido, que es lo que fija la fecha ante un tercero.

La clave pública

La publicamos en tres sitios, y los tres dan lo mismo:

https://uttera.ai/.well-known/uttera-firma.pub     el PEM, a secas
https://uttera.ai/.well-known/uttera-firma.json    todas las claves, con sus fechas
https://api.uttera.ai/v1/reports/public-key        la que está firmando ahora

La cadena de confianza es la misma que usan DKIM o los conjuntos de claves JWKS: el certificado TLS de uttera.ai acredita que el dominio es nuestro, y ese dominio publica la clave. No hace falta que te fíes de nosotros por teléfono.

Comprobarlo desde la línea de órdenes

El endpoint es público y no lleva clave de API:

POST https://api.uttera.ai/v1/reports/verify

Con el PDF y nada más. Es el modo normal: la firma va dentro del fichero, así que no hace falta nada que hayas tenido que guardar aparte. Comprueba las dos firmas de una vez:

curl -s -X POST https://api.uttera.ai/v1/reports/verify \
  -H "Content-Type: application/json" \
  -d "{\"modo\":\"pdf\",\"pdf_b64\":\"$(base64 -w0 informe.pdf)\"}"

{"mode": "pdf", "signed": true,
 "valid_container": true, "valid_content": true,
 "key_fingerprint": "56ac333b…",
 "fields": {"cliente": "…", "titulo": "…", "generado": "1789641036", …}}

Las dos a true es el caso bueno. valid_content a true con valid_container a false quiere decir que el texto es el nuestro pero el fichero se ha vuelto a guardar —cualquier herramienta de PDF que lo abra y lo escriba cambia los bytes—, que no es lo mismo que una falsificación. signed a false es que el fichero no lleva firma nuestra, o que se la han quitado.

Los dos modos que siguen son para cuando tienes las piezas sueltas: un informe antiguo, o la firma archivada aparte.

Comprobar el fichero (firma de contenedor). Necesitas el PDF y la firma que vino con él en report.container_signature:

curl -s -X POST https://api.uttera.ai/v1/reports/verify \
  -H "Content-Type: application/json" \
  -d "{\"modo\":\"contenedor\",
       \"pdf_b64\":\"$(base64 -w0 informe.pdf)\",
       \"firma_b64\":\"LA_FIRMA_DE_CONTENEDOR\"}"

{"valid": true, "mode": "contenedor", "key_fingerprint": "56ac333b…"}

Comprobar el contenido. Necesitas la respuesta del análisis tal cual te la devolvimos, más report.content_signature y la fecha de report.generated_unix — el sello unix, que es el valor que se firmó; generated_at es la fecha escrita, para leer. El sello va impreso en el propio informe, junto al número:

curl -s -X POST https://api.uttera.ai/v1/reports/verify \
  -H "Content-Type: application/json" \
  -d '{"modo":"contenido",
       "datos": { …la respuesta de /v1/summarize… },
       "cliente":"Meridiano Asesores, S.L.",
       "titulo":"Acta de la reunión",
       "generado":1789639533,
       "firma_b64":"LA_FIRMA_DE_CONTENIDO"}'

No guardamos nada para esto. Verificar es una operación de clave pública sobre lo que nos mandas: no consultamos ningún registro. Por eso funciona con un informe de hace años, y por eso no podemos decirte cuántos informes hemos emitido ni buscarte uno que hayas perdido.

Rotación de claves

Cada clave se usa doce meses, y se cambia antes si hay cualquier sospecha. Las claves retiradas se quedan publicadas para siempre: un informe firmado hoy tiene que poder verificarse dentro de diez años.

Por eso cada informe lleva impresa, además de su firma, la huella de la clave que lo firmó. El verificador sabe cuál usar sin tener que probarlas todas.

Si alguna vez tuviéramos que retirar una clave por compromiso, lo diríamos aquí con la fecha. Y diríamos también lo incómodo: los informes firmados con ella dejan de probar nada, porque quien tuviera la clave podría haber firmado documentos con fecha anterior.