Producir un informe con inteligencia artificial puede llevar minutos. Comprobar si sus argumentos, cifras y referencias se sostienen sigue exigiendo atención y conocimiento. Google quiere intervenir precisamente en esa segunda parte con Deep Review, un sistema que examina documentos extensos y devuelve observaciones sobre su lógica, sus afirmaciones y su claridad.
El lanzamiento público se anunció el 14 de octubre de 2026. La propuesta procede de una herramienta experimental para autores de artículos científicos, pero ahora se presenta para otros documentos de trabajo. La novedad no es una garantía automática de veracidad: es una revisión asistida que también necesita ser revisada.
La respuesta breve: Deep Review divide el documento, reparte el esfuerzo de análisis entre agentes y reúne sus observaciones en un informe. Puede ayudar a localizar problemas; no certifica que el texto sea correcto, no reproduce por sí solo todos los experimentos y no sustituye una decisión experta. Hay, además, diferencias entre el anuncio y el portal que conviene conocer antes de utilizarlo.
Qué es Deep Review y qué cambia respecto a pedir «revísame este texto»
Según el anuncio de Google Research del 14 de octubre, Deep Review es un sistema de agentes orientado a proporcionar comentarios y comprobaciones técnicas sobre documentos complejos. Busca inconsistencias lógicas, examina enunciados matemáticos, contrasta afirmaciones y compara el contenido con trabajos existentes.
Su antecedente es Paper Assistant Tool, conocido como PAT. En los programas científicos, los autores podían solicitar observaciones privadas antes de presentar sus manuscritos. Esa función es distinta de la evaluación oficial de un congreso: recibir comentarios del sistema no significa haber superado la revisión por pares ni haber obtenido una aceptación.
La diferencia conceptual frente a un único mensaje a un chatbot está en la organización del trabajo. Una petición general puede dedicar demasiada atención a la introducción, perder una dependencia entre secciones o producir una valoración convincente sin examinar el detalle decisivo. La arquitectura intenta repartir esa carga. Que exista esa organización no demuestra que cada observación vaya a ser acertada.
Las cuatro fases que describe Google
1. Dividir sin perder el contexto
Un agente segmenta el documento en unidades lógicas, como metodología, experimentos o introducción. Los segmentos pueden solaparse y, según la descripción del sistema, deben cubrir todo el contenido. La intención es que una sección difícil no quede relegada por la longitud total del archivo.
2. Dedicar más cálculo a lo más exigente
El sistema distribuye un presupuesto de procesamiento según la densidad del contenido. Una demostración matemática puede requerir más esfuerzo que un párrafo introductorio. Este reparto adaptativo es una decisión de diseño, no una promesa de que todos los posibles errores recibirán la atención necesaria.
3. Analizar secciones en paralelo
Varios agentes se concentran en partes concretas, conservando acceso al contexto del documento completo para seguir referencias cruzadas. Resulta importante porque una conclusión puede depender de una definición situada muchas páginas antes. Aun así, disponer de ese contexto no garantiza interpretarlo correctamente.
4. Reunir observaciones y contrastar
Un agente de síntesis consolida los informes, comprueba la coherencia entre secciones y puede realizar búsquedas externas y llamadas a herramientas. Ese contraste busca reducir afirmaciones inventadas. No debe confundirse con una prueba formal de corrección ni con una auditoría independiente de los datos originales.
La distinción con la recuperación documental también importa. Nuestra explicación de RAG y documentos fiables aborda cómo aportar fuentes a un asistente. Localizar una fuente y evaluar si realmente justifica una conclusión son tareas relacionadas, pero no equivalentes.
Qué demuestran los pilotos científicos y qué no
El anuncio de octubre atribuye a los programas previos comentarios sobre más de 16.000 manuscritos de autores participantes en STOC, ICML, NeurIPS e ICLR. El portal consultado el 17 de octubre habla de más de 15.000 trabajos e incluye AISTATS en su relación. Son formulaciones distintas: no las sumamos ni las presentamos como un censo homogéneo de artículos aceptados.
Para interpretar la evidencia resulta más útil acudir a un programa concreto. La retrospectiva oficial de ICML, publicada el 30 de marzo de 2026, describe un piloto del 14 al 26 de enero, con aproximadamente 4.500 artículos y 869 respuestas a su encuesta posterior.
- El 92,1 % de quienes respondieron dijo que volvería a utilizar la herramienta.
- El 73,3 % calificó los comentarios como muy útiles o mayoritariamente útiles.
- El 35,4 % de los autores de trabajos con teoría comunicó lagunas teóricas significativas que requirieron más de una hora de corrección.
- El 31 % de los autores de trabajos con resultados experimentales señaló que los comentarios le llevaron a realizar nuevos experimentos.
Estas cifras describen respuestas de participantes y subgrupos, no una tasa objetiva de detección de todos los errores existentes. Tampoco prueban cuánto mejoró la corrección final frente a un grupo comparable sin asistencia. La decisión de participar y de contestar la encuesta puede influir en los resultados.
El portal actual anuncia también un 60 % de autores que realizaron experimentos nuevos. No trasladamos esa cifra al piloto de ICML: su retrospectiva identifica un 31 % para su subgrupo experimental. Sin una correspondencia explícita entre muestras, versiones y preguntas, comparar esos porcentajes como una mejora medida sería una inferencia injustificada.
La explicación del programa STOC reconoce observaciones equivocadas y dificultades con notación compleja o figuras. Sus autores expertos filtraban los comentarios y los utilizaban como punto de partida para comprobar. Esa mediación humana forma parte de la utilidad observada, no es un detalle prescindible.
Acceso, formatos y costes: lo anunciado frente a lo visible
Google anuncia disponibilidad mundial y dos revisiones gratuitas por semana. El portal público de Deep Review, consultado el 17 de octubre, muestra acceso mediante cuenta de Google, carga de documentos y una opción para pegar texto. Esta redacción ha consultado la documentación pública; no ha subido un manuscrito ni medido la calidad de una revisión propia.
Los formatos requieren una precisión. El anuncio inicial indica PDF y texto, con entradas de varios archivos previstas para más adelante. Las preguntas frecuentes del portal ya enumeran también Google Docs y Google Slides. No puede deducirse de esa lista cómo se habilita cada modalidad en cada cuenta. Si una opción no aparece en la interfaz, conviene confirmar su disponibilidad en vez de asumir que pegar un enlace concede acceso al documento.
Para un volumen superior, el portal permite aportar una clave de Gemini API y pagar las llamadas a los modelos. La ausencia de una tarifa adicional específica de Deep Review no convierte esas ejecuciones en gratuitas. La página ofrece estimaciones variables según documento, modelo y esfuerzo; no hay un precio universal por revisión que podamos garantizar.
Antes de una integración, una precaución razonable es establecer límites de gasto y probar un documento no sensible. Es una recomendación de control operativo, no una afirmación de que una revisión larga vaya a tener un coste concreto. Tampoco se debe trasladar el tiempo medio del antiguo piloto a una garantía de entrega del servicio público.
Privacidad: no entrenar con el archivo no significa no conservarlo
El anuncio afirma que los documentos no se utilizan para entrenar, ajustar o mejorar los modelos y que se conservan durante un año para mostrarlos al usuario. El portal introduce un matiz: habla de no utilizarlos sin permiso y de una posibilidad de autorizar su uso para mejorar Deep Review. Ambas páginas describen conservación; ninguna justifica asumir borrado inmediato tras recibir el informe.
La consecuencia práctica es revisar las condiciones y opciones efectivas antes de cargar un archivo. Un documento público y uno que contiene información de clientes no son intercambiables. Para una primera prueba, utilizar material propio y no confidencial reduce la exposición sin impedir evaluar la utilidad de los comentarios.
Google también indica que el sistema puede buscar trabajos relacionados en la web. Eso no demuestra que se publique el manuscrito, pero sí obliga a entender el recorrido de los datos antes de integrar contenido reservado. La información pública consultada no basta para certificar el cumplimiento de las obligaciones de una organización concreta.
En documentación jurídica, financiera o con datos personales, el resultado debe tratarse como ayuda de revisión, no como asesoramiento profesional ni autorización para compartir información. Si no se dispone del permiso necesario o no se comprende la política aplicable, no se debería subir el archivo.
Un procedimiento útil: convertir cada comentario en una comprobación
El mayor riesgo editorial no es recibir una sugerencia floja, sino incorporar una corrección errónea porque llega redactada con autoridad. Proponemos un procedimiento de trabajo propio, no un protocolo oficial de Google, para mantener la revisión bajo control.
- Guardar una versión de partida. Conservar el archivo enviado, su fecha y sus fuentes permite saber qué se examinó y evita atribuir una observación a una versión posterior.
- Clasificar las observaciones. Separar claridad de redacción, contradicciones internas, referencias pendientes y posibles errores técnicos. Una preferencia estilística no equivale a una refutación.
- Exigir una localización. Anotar página, párrafo, fórmula o gráfico afectado. Un comentario demasiado general necesita concreción antes de modificar el texto.
- Comprobar con evidencia independiente. Abrir la referencia original, rehacer la cuenta o consultar a alguien con experiencia. La explicación del mismo sistema no es una segunda validación independiente.
- Registrar una decisión. Aceptar, rechazar o dejar pendiente cada observación con una razón breve. No cambiar silenciosamente una conclusión central.
- Revisar el documento final completo. Una corrección local puede romper una tabla, una referencia cruzada o la coherencia de la conclusión.
Un ejemplo hipotético: un informe afirma que una campaña aumentó las ventas un 20 %, pero compara facturación en un apartado y número de pedidos en otro. La revisión puede señalar la diferencia. La solución no es sustituir automáticamente un indicador: hay que volver a los datos y decidir qué comparación es válida.
En trabajos científicos, esa misma disciplina evita confundir una cita relacionada con evidencia suficiente. El análisis de AstaBrief y la comprobación de informes con citas desarrolla ese problema desde la elaboración de informes; aquí el foco está en revisar un documento ya escrito y documentar las decisiones posteriores.
Qué mirar antes de automatizar la revisión editorial
Una integración responsable no debería transformar cada observación en una edición automática. Es más prudente generar una lista de incidencias y reservar la aprobación para cambios de cifras, afirmaciones relevantes o conclusiones. Además, un documento analizado debe tratarse como contenido, no como una fuente autorizada de instrucciones para ejecutar acciones externas.
Para quienes están aprendiendo a organizar contenidos, el análisis de la membresía Sofía IA — ABE IA permite valorar una propuesta formativa general. No implica que esa formación incluya Deep Review ni que Google la respalde.
Si el objetivo es trabajar con borradores largos destinados a lectores, también puede consultarse nuestro análisis del curso de creación de ebooks con IA de Johe Magdalena. Es otro contexto editorial, no una acreditación científica ni una promesa de resultados. La revisión de fuentes sigue siendo necesaria con independencia del método de escritura.
Preguntas frecuentes sobre Deep Review
¿Sustituye a un revisor humano?
No. Los pilotos descritos ofrecían comentarios a los autores por separado del proceso oficial. Su utilidad consiste en ayudar a detectar problemas antes de una evaluación experta, no en reemplazarla.
¿Una revisión sin advertencias demuestra que el documento es correcto?
No. Puede haber errores omitidos, referencias mal interpretadas o datos que el sistema no pueda comprobar. Ausencia de observaciones no equivale a ausencia de fallos.
¿Es gratuito?
La oferta pública consultada contempla dos revisiones semanales gratuitas. Las adicionales mediante una clave propia pueden generar costes de Gemini API. Hay que comprobar las condiciones vigentes antes de activar ese uso.
¿Puedo enviar varios archivos y cualquier documento privado?
No debe darse por hecho. El anuncio presenta el soporte de varios archivos como futuro y la privacidad depende de condiciones, permisos y opciones concretas. Para documentos reservados, primero hay que resolver esas cuestiones.
La mejora importante es revisar mejor, no producir otro sello automático
Deep Review plantea una dirección útil: dedicar capacidad de IA a cuestionar documentos, no solo a generarlos. Sus antecedentes muestran que algunos autores encontraron observaciones valiosas y realizaron cambios sustanciales. No demuestran infalibilidad ni permiten extrapolar el resultado a cualquier disciplina.
La decisión práctica es mantener una cadena visible entre comentario, evidencia y corrección. Si la herramienta ayuda a encontrar una contradicción verificable, aporta valor. Si su informe se acepta como certificado sin contrastarlo, el cuello de botella no desaparece: queda escondido detrás de una nueva capa de texto.
Información contrastada el 17 de octubre de 2026 con el anuncio de Google Research, el portal del servicio y las retrospectivas oficiales de los pilotos. Las diferencias entre páginas se indican expresamente; no se ha realizado una prueba con documentos privados.