IAs para crear manuales técnicos: comparación práctica con un mismo brief

Si necesitas preparar el primer borrador de un manual técnico, la pregunta importante no es solo qué IA redacta mejor. También necesitas saber si respeta la información fuente, reconoce lo que falta y corrige sus errores cuando recibe feedback.

En la prueba controlada de GanaConIA, ChatGPT produjo el mejor borrador final entre los outputs evaluados: obtuvo 94/100 en la primera ronda y 97/100 después de la corrección. Gemini pasó de 52/100 a 82/100 y mostró la mayor capacidad de corrección observada en esta prueba; su versión específica no fue verificable y no está demostrada la equivalencia exacta del modelo interno entre R1 y R2. Claude avanzó de 70/100 a 79/100.

Estos resultados pertenecen exclusivamente a una tarea, un brief ficticio, dos rondas y las condiciones registradas el 30 y 31 de agosto de 2026. No demuestran que una plataforma sea universalmente mejor para crear manuales técnicos.

La parte más útil del ejercicio fue otra: mostró cómo una IA puede convertir un vacío documental en una instrucción plausible, y cómo diseñar un proceso para impedirlo.

Qué comparamos y por qué

Pedimos a ChatGPT, Claude y Gemini que crearan el primer borrador verificable del manual de un producto ficticio: el monitor ambiental TermoSense TS-100.

Una misma tarea y un mismo brief

Las tres plataformas recibieron el mismo usuario objetivo, las mismas especificaciones, las mismas advertencias y las mismas tareas. El brief era la única fuente autorizada.

El manual debía explicar, entre otras acciones, la carga, el encendido, la vinculación con una aplicación ficticia, la configuración de umbrales, la lectura de mediciones, la exportación CSV y el reinicio.

Había una dificultad intencional: el brief nombraba esas tareas, pero no entregaba todos los procedimientos. Una salida segura debía reconocer el vacío en vez de completarlo con conocimiento general.

Dos rondas con objetivos distintos

• Ronda 1: una generación zero-shot con el prompt y brief congelados.
• Ronda 2: cada IA recibió su propio borrador, el mismo brief y feedback humano específico sobre sus errores.

Ninguna recibió los outputs, puntuaciones o comentarios de las otras plataformas.

La misma rúbrica para todos

Evaluamos cada borrador sobre 100 puntos:

Una frase técnicamente plausible no recibía crédito si no estaba respaldada por el brief.

Qué pedimos a las IA

El prompt no se limitaba a decir «escribe un manual». Definía siete bloques:

• ROLE: qué función debía asumir la IA.
• OBJECTIVE: qué resultado debía producir.
• CONTEXT: cuál era la fuente de verdad y qué límites existían.
• INPUT DATA: especificaciones, advertencias y tareas.
• RESTRICTIONS: qué no podía inventar.
• OUTPUT FORMAT: estructura obligatoria.
• QUALITY CRITERION: cómo reconocer una salida aceptable.

La regla central era sencilla: si faltaba información necesaria, debía escribir INFORMACIÓN FALTANTE y formular una pregunta para el responsable técnico.

El prompt experimental completo y el brief deben conservarse como evidencia complementaria. Más adelante encontrarás una versión reutilizable para adaptar el método a otro producto.

Resultados de la primera ronda

ChatGPT produjo el resultado inicial más fiel en este ejercicio. Claude y Gemini identificaron varios faltantes, pero en diferentes pasajes presentaron como ejecutables procedimientos que el brief no documentaba.

El problema más importante: inventar lo que el brief no dice

Plausible no significa autorizado

Una instrucción puede sonar correcta y seguir siendo impropia para un manual técnico. Si la documentación fuente no explica cómo activar el modo de vinculación, la IA no debería elegir una combinación de botones, inventar una pantalla ni aplicar un procedimiento Bluetooth genérico.

Eso no se resuelve agregando al final una nota de duda. El supuesto debe desaparecer del procedimiento y ser sustituido por un faltante verificable.

Ejemplos observados en la prueba

Entre los problemas registrados aparecieron estas familias:

• convertir Bluetooth 5.0 del producto en un requisito para el teléfono;
• asumir que el dispositivo «emite una señal» al entrar en vinculación;
• inventar selección y confirmación dentro de ClimaDesk;
• convertir rangos de medición en límites configurables u operativos;
• afirmar que un sistema genera, descarga o guarda un CSV sin conocer el flujo;
• describir qué ocurre al reiniciar el dispositivo sin una fuente.

No significa que esas acciones sean imposibles. Significa que el brief no las autorizaba.

Cómo usar INFORMACIÓN FALTANTE

Un marcador útil debe hacer tres cosas:

1. detener la instrucción antes de la suposición;
2. identificar el dato que falta;
3. convertirlo en una pregunta concreta.

Ejemplo:

INFORMACIÓN FALTANTE: ¿Qué acción debe realizar el usuario para entrar en modo de vinculación y qué señal confirma que el dispositivo está listo?

Esa pregunta puede enviarse a ingeniería, soporte, producto o la persona responsable de la fuente. El manual no debería aprobarse hasta resolverla.

Por qué importa en documentación técnica

Una invención en un texto promocional puede ser un error factual. En un manual también puede transformarse en una acción inejecutable, una incompatibilidad o una instrucción insegura. Por eso la fluidez nunca debe tener prioridad sobre la trazabilidad.

Qué pasó cuando dimos feedback

La segunda ronda no fue una nueva generación libre. Cada plataforma recibió:

• su propio output íntegro de R1;
• el brief original;
• una revisión humana con cita, categoría, fundamento y acción requerida;
• instrucciones para conservar lo correcto y eliminar lo no respaldado.

El feedback señalaba el problema, pero no entregaba la frase corregida. Así podíamos observar si la IA sabía aplicar la revisión, no solo copiar una solución humana.

También exigimos tres bloques: tabla de cambios, borrador completo de 1.200 a 1.600 palabras y asuntos pendientes.

Resultados de la segunda ronda

La mejora relativa sobre el margen disponible fue 50,0 % para ChatGPT, 30,0 % para Claude y 62,5 % para Gemini.

Estas métricas describen cuánto avanzó cada output desde puntos de partida diferentes. No convierten automáticamente al que más mejoró en el mejor documento final.

Mejor resultado final y mayor capacidad de corrección no son lo mismo

Calidad absoluta del borrador final

ChatGPT obtuvo 97/100 y produjo el mejor output final de R2 entre los tres evaluados. Conservó las especificaciones, marcó los procedimientos desconocidos y cumplió la extensión con 1.547 palabras.

Mejora respecto del primer intento

Gemini avanzó 30 puntos y utilizó el 62,5 % de su margen disponible. Fue la mayor capacidad de corrección observada en esta prueba, aunque su documento final quedó por debajo del de ChatGPT. La versión específica no fue verificable y no está demostrada la equivalencia exacta del modelo interno entre R1 y R2.

Claude mejoró nueve puntos. Sin embargo, la evolución no mide puramente un mismo modelo: en R1 estaba configurado claude-opus-5, pero el modelo efectivo no fue verificable; en R2 se seleccionó manualmente claude-haiku-4-5.

Seguir feedback y conservar información válida

Corregir no consiste en borrar todo lo dudoso. Una revisión sólida debe:

• retirar lo inventado;
• conservar especificaciones y advertencias correctas;
• convertir vacíos en preguntas;
• no introducir errores nuevos;
• respetar formato y extensión.

Cumplimiento formal

ChatGPT declaró haber corregido la secuencia de inspección, pero el borrador conservó 1, 2, 1. Gemini declaró cumplir el máximo de 1.600 palabras, aunque el conteo independiente encontró 1.623. Las tablas de cambios también necesitan QA.

ChatGPT en esta prueba

Lo observado en R1 y R2

ChatGPT comenzó con 94/100 y cero invenciones críticas. Tras el feedback llegó a 97/100. Corrigió la localización no documentada del USB-C y redujo el borrador al rango exigido, pero mantuvo la numeración incorrecta pese a declararla corregida.

Según la documentación oficial consultada el 31/08/2026, ChatGPT admite formatos comunes como PDF, DOCX, PPTX, TXT, CSV y XLSX. OpenAI documentaba un límite de 512 MB por archivo y 2 millones de tokens para archivos de texto o documentos. Esos límites son datos variables y no formaron parte de la puntuación experimental.

La documentación oficial también describe memoria, búsqueda web y controles de datos. Para un flujo reproducible conviene revisar esas opciones y evitar que contexto anterior o búsqueda externa alteren una prueba basada en una única fuente.

Cuándo podría encajar

En este ejercicio resultó adecuado para producir un primer borrador conservador a partir de una fuente limitada. Eso no garantiza el mismo comportamiento con otro modelo, plan, documento o producto real.

Claude en esta prueba

Lo observado en R1 y R2

Claude pasó de 70/100 a 79/100. En R2 eliminó seis de nueve familias críticas, pero mantuvo un protocolo de troubleshooting no documentado y varias definiciones o afirmaciones externas al brief.

La desviación metodológica es importante:

• R1: claude-opus-5 configurado; modelo efectivo no verificable.
• R2: claude-haiku-4-5, seleccionado manualmente.

No es correcto presentar esos nueve puntos como la corrección pura de una misma versión.

La documentación oficial consultada indicaba que Claude admite carga de archivos y publicaba límites diferentes para chats y Projects. También describe Projects como espacios con documentos y contexto. Memoria, búsqueda y límites dependen del producto, modo, modelo o plan; incluso la documentación consultada distinguía experiencias actuales y heredadas. Por eso el artículo no atribuye a «Claude» una configuración única.

Cuándo podría encajar

Puede considerarse para flujos documentales con archivos y contexto organizado, pero esta prueba no demuestra cuál modelo de Claude sería más adecuado ni permite comparar limpiamente las dos rondas como una misma versión.

Gemini en esta prueba

Lo observado en R1 y R2

Gemini comenzó con 52/100 y terminó con 82/100. Eliminó cinco familias críticas y seis menores. Aun así, mantuvo tres problemas críticos parcialmente corregidos, dos menores, una autocontradicción y errores formales.

Fue la mayor mejora observada, no el mejor resultado final.

En ambas rondas la interfaz mostró únicamente Gemini. No se verificó una versión específica ni puede demostrarse que el modelo interno fuera exactamente el mismo.

La documentación oficial consultada el 31/08/2026 indicaba que Gemini Apps admite la mayoría de tipos de archivo, hasta 10 archivos por prompt sujeto a disponibilidad y hasta 100 MB para archivos no audiovisuales. Google también documenta memoria de chats, actividad y Deep Research bajo condiciones de cuenta, configuración y plan. En R2 había contexto personal preinyectado de forma pasiva, pero no se observó una llamada activa de memoria ni navegación web.

Cuándo podría encajar

En este ejercicio mostró capacidad para responder a feedback detallado. No demuestra que Gemini corrija mejor en general ni permite atribuir el resultado a una versión interna concreta.

Cómo crear un manual técnico con IA sin dejar que invente datos

Esta es la parte que puedes reutilizar con cualquier plataforma.

Paso 1. Reúne la fuente autorizada

Agrupa especificaciones, versiones, piezas, advertencias, procedimientos aprobados, interfaces y resultados esperados. Si existen documentos contradictorios, resuelve primero cuál prevalece.

Paso 2. Separa datos conocidos y ausentes

Haz dos listas. La segunda no es un defecto: es el inventario de preguntas que ingeniería o producto debe responder.

Paso 3. Prohíbe completar huecos

No confíes en frases vagas como «no alucines». Indica qué no puede añadir: botones, pantallas, funciones, compatibilidades, secuencias y resultados.

Paso 4. Define INFORMACIÓN FALTANTE

Exige el marcador exacto y una pregunta concreta. El faltante debe sustituir el procedimiento desconocido, no aparecer después de una instrucción inventada.

Paso 5. Exige trazabilidad

Cada afirmación técnica debe poder vincularse a la fuente. Si no puede, se elimina o se convierte en pregunta.

Paso 6. Genera el primer borrador

Define usuario, alcance, secciones, longitud y resultado. Guarda el input y output íntegros.

Paso 7. Revisa afirmaciones y procedimientos

Clasifica datos correctos, omisiones, cambios, invenciones e inferencias no autorizadas. No premies un texto solo porque suena profesional.

Paso 8. Da feedback específico

Incluye una cita breve, categoría, fundamento y acción requerida. No entregues siempre la reescritura: así puedes comprobar si la IA aplica el criterio.

Paso 9. Contrasta la versión corregida

Revisa el borrador, no solo la tabla donde la IA dice qué cambió.

Paso 10. Ejecuta QA humano

Una persona responsable debe validar especificaciones, seguridad, secuencias, interfaces, capturas y comportamiento del producto antes de publicar o usar el manual.

Prompt reutilizable para crear un primer borrador

Reemplaza las variables entre corchetes con información autorizada. Si un dato no existe, no lo completes antes de usar el prompt.

ROLE
Actúa como redactor técnico bajo control estricto de fuentes.

OBJECTIVE
Genera el primer borrador verificable de un manual para [PRODUCTO], destinado a [USUARIO], que permita completar [OBJETIVO].

CONTEXT
La información incluida en INPUT DATA es la única fuente autorizada. No eres la autoridad final sobre especificaciones, seguridad, compatibilidad ni procedimientos. El borrador será revisado por una persona responsable antes de publicarse o utilizarse.

INPUT DATA
PRODUCTO: [PRODUCTO]
USUARIO: [USUARIO]
OBJETIVO: [OBJETIVO]
DATOS TÉCNICOS: [DATOS_TÉCNICOS]
ADVERTENCIAS: [ADVERTENCIAS]
TAREAS: [TAREAS]
FORMATO REQUERIDO: [FORMATO]

RESTRICTIONS
1. No añadas especificaciones, piezas, funciones, pantallas, botones, aplicaciones, compatibilidades, explicaciones técnicas ni procedimientos ausentes de INPUT DATA.
2. Si falta información necesaria, no la inventes. Escribe exactamente INFORMACIÓN FALTANTE y formula la pregunta que debe responder el responsable correspondiente.
3. INFORMACIÓN FALTANTE debe sustituir el supuesto. No presentes primero el procedimiento desconocido como hecho.
4. Conserva literalmente nombres, versiones, valores, medidas, unidades, componentes y advertencias.
5. Presenta una acción principal por paso y un resultado observable solo cuando la fuente lo permita.
6. Sitúa cada advertencia antes del procedimiento al que afecta.
7. No afirmes haber probado el producto.
8. No inventes capturas. Usa [CAPTURA NECESARIA: descripción].
9. No uses conocimiento general, navegación ni fuentes externas para completar el manual.

OUTPUT FORMAT
Entrega un borrador completo con: título, alcance, usuario, componentes, especificaciones, advertencias, preparación, procedimientos numerados, resultados esperados, troubleshooting, mantenimiento, glosario, información faltante y checklist de revisión humana.

QUALITY CRITERION
Cada afirmación técnica debe poder rastrearse a INPUT DATA. El lector debe distinguir qué necesita, qué puede hacer, qué debería observar, qué no debe hacer y qué información sigue pendiente. Prioriza fidelidad y seguridad sobre fluidez.

Checklist de QA antes de aprobar el manual

• Modelo, piezas, valores, unidades y versiones coinciden con la fuente.
• Cada procedimiento está documentado; no solo nombrado.
• Las advertencias aparecen antes de la acción relevante.
• Botones, pantallas, menús y aplicaciones existen en la documentación.
• Los resultados observables están respaldados.
• Los datos ausentes usan INFORMACIÓN FALTANTE y una pregunta concreta.
• Las fuentes y su versión o fecha están identificadas.
• Las capturas son reales, actuales y corresponden al producto.
• La terminología es consistente.
• Las referencias cruzadas apuntan a secciones existentes.
• La tabla de cambios coincide con el borrador real.
• Una persona responsable revisó el documento.
• El procedimiento fue validado con el producto real antes de utilizarse.

Si te aparece esto: problemas y qué hacer

La IA inventa botones o combinaciones

Problema: aparece una secuencia que no está en la fuente.
Por qué importa: puede volver el procedimiento inejecutable o inseguro.
Cómo detectarlo: busca cada botón y duración en la documentación autorizada.
Qué hacer: elimina el paso, marca INFORMACIÓN FALTANTE y pregunta por la secuencia exacta.

Inventa pantallas, menús o confirmaciones

Problema: el manual menciona una ruta de interfaz no documentada.
Por qué importa: el usuario no podrá reproducirla y una actualización puede cambiarla.
Cómo detectarlo: exige fuente o captura auténtica para cada pantalla.
Qué hacer: sustituye la ruta por una pregunta y deja un marcador de captura.

Convierte rangos de medición en límites operativos

Problema: un rango del sensor se transforma en límite ambiental, umbral o recomendación.
Por qué importa: cambia el significado técnico del dato.
Cómo detectarlo: compara la etiqueta original de cada valor con el uso que recibe en el manual.
Qué hacer: restaura el dato en su categoría original y solicita los límites operativos por separado.

Añade pasos plausibles

Problema: la secuencia parece lógica, pero no aparece en la fuente.
Por qué importa: plausibilidad no equivale a verificación.
Cómo detectarlo: obliga a rastrear cada acción.
Qué hacer: elimina la acción y formula la pregunta que falta.

Afirma haber corregido algo que sigue presente

Problema: la tabla de cambios y el borrador no coinciden.
Por qué importa: crea una falsa sensación de cierre.
Cómo detectarlo: busca el fragmento original dentro del documento corregido.
Qué hacer: revisa ID por ID y registra CORREGIDO, PARCIAL o NO CORREGIDO.

Cumple el contenido, pero falla el formato

Problema: extensión, numeración o secciones incumplen la instrucción.
Por qué importa: afecta usabilidad y puede ocultar contenido fuera del bloque evaluado.
Cómo detectarlo: cuenta palabras de forma independiente y valida la estructura.
Qué hacer: corrige el formato sin alterar datos ni borrar faltantes esenciales.

Elimina información válida para evitar errores

Problema: la corrección vuelve el texto seguro, pero incompleto.
Por qué importa: corregir también exige preservar lo respaldado.
Cómo detectarlo: compara especificaciones y advertencias antes/después.
Qué hacer: restaura la información válida sin reincorporar los supuestos.

Da por hecho cómo funciona una aplicación

Problema: aparecen menús, descargas o confirmaciones no documentadas.
Por qué importa: las interfaces cambian y pueden depender de versión o plan.
Cómo detectarlo: verifica la documentación y la interfaz real de la versión objetivo.
Qué hacer: fecha la comprobación, añade captura auténtica y marca cualquier diferencia como faltante.

Qué IA elegir para preparar un manual técnico

Si tu prioridad es el mejor borrador final observado en este ejercicio, ChatGPT fue el resultado más sólido. Si quieres evaluar cuánto puede recuperarse una salida débil después de feedback detallado, Gemini mostró la mayor mejora observada en esta prueba; su versión específica no fue verificable y no está demostrada la equivalencia exacta del modelo interno entre R1 y R2. Claude avanzó, pero el cambio de modelo impide leer sus dos rondas como una comparación limpia de la misma versión.

La decisión real no debería depender solo de esas notas. Antes de elegir, revisa:

• qué formatos y tamaños de archivo necesitas;
• cómo controlarás memoria, contexto y búsqueda;
• qué política de datos corresponde a tu cuenta;
• quién validará los procedimientos;
• cómo conservarás fuentes, prompts, outputs y cambios.

La herramienta prepara el borrador. La aprobación técnica sigue siendo humana.

Limitaciones de la prueba

• Se evaluó una sola tarea y un producto ficticio.
• No hubo hardware, aplicación real ni documentación de ingeniería completa.
• Las condiciones de memoria, modo y herramientas no fueron idénticas.
• En ChatGPT, algunos metadatos de modo y memoria no fueron verificables.
• Claude cambió de condición de modelo entre rondas.
• Gemini no mostró una versión específica en ninguna ronda.
• Gemini R2 tuvo contexto personal preinyectado pasivamente.
• Las funciones oficiales consultadas pueden cambiar después del 31/08/2026.
• No se probó Document360 en condiciones comparables.
• Las puntuaciones no clasifican universalmente a las plataformas.

Metodología y transparencia

Fechas y condiciones

La prueba se ejecutó el 30 y 31 de agosto de 2026. Se conservaron prompts, outputs, feedback, registros de ejecución y evaluaciones. No se pidió una tercera ronda.

Modelos mostrados

• ChatGPT R1/R2: GPT-5.6 Sol.
• Claude R1: claude-opus-5 configurado; modelo efectivo no verificable.
• Claude R2: claude-haiku-4-5 seleccionado manualmente.
• Gemini R1/R2: Gemini; versión específica no verificable.

Navegación y contexto

No se observó navegación web durante las generaciones evaluadas. Las condiciones de memoria y herramientas quedaron registradas por ejecución y se analizaron separadas de las puntuaciones.

Tratamiento de los outputs

Los outputs se conservaron íntegros. La evaluación comparó cada borrador con el brief, contó de forma independiente el bloque corregido y contrastó lo que cada tabla decía haber corregido con el contenido real.

Fuentes oficiales consultadas

Información comprobada el 31/08/2026:

OpenAI/ChatGPT

• Tipos de archivos compatibles
• Preguntas frecuentes sobre carga de archivos
• Cómo funciona la carga de archivos
• Memoria de ChatGPT
• Búsqueda web en ChatGPT
• Controles de datos

Anthropic/Claude

• Carga de archivos en Claude
• Projects en Claude
• Límites de uso y longitud
• Memoria y búsqueda de chats
• Búsqueda web
• Uso de datos en productos de consumo

Google/Gemini

• Carga y análisis de archivos
• Memoria de chats anteriores
• Deep Research
• Centro de privacidad de Gemini Apps
• Gestión de actividad de Gemini Apps

Actualización

• Prueba realizada: 30–31/08/2026.
• Información de productos verificada: 31/08/2026.
• Última revisión del artículo: 31/08/2026, borrador no publicado.