La conversación sobre los modelos frontera suele empezar mal: “¿Cuál es el mejor?”. Es una pregunta cómoda, pero no ayuda mucho cuando hay que decidir qué herramienta va a tocar documentos, correo, código o conocimiento interno.
Este artículo se apoya en documentación oficial de OpenAI, Anthropic, Microsoft/GitHub y Google. La conclusión no es una clasificación. ChatGPT, Claude, Copilot y Gemini cambian de versión, de plan y de funciones con bastante frecuencia. Para una empresa de Donostia, Gipuzkoa o Euskadi, importa más otra cosa: qué trabajo quieres resolver, qué datos puede ver la herramienta y quién revisa el resultado.
Antes de comparar: no son cuatro cosas equivalentes
ChatGPT, Claude y Gemini son asistentes que agrupan distintos modelos y funciones bajo una misma interfaz. “Copilot” merece una aclaración: Microsoft y GitHub usan ese nombre para varios productos, desde ayuda en Microsoft 365 hasta asistencia para programar y agentes de desarrollo. Compararlo como si fuese un único modelo sería simplificar demasiado.
Por eso, una comparación útil no consiste en coronar un ganador. Consiste en detectar dónde vive el trabajo:
- Si el problema está en documentos, procedimientos, correos y análisis, prueba asistentes de propósito general con ejemplos reales de tu empresa.
- Si el trabajo ocurre dentro de Microsoft 365, GitHub o un IDE, revisa primero el Copilot correspondiente y sus permisos.
- Si el equipo trabaja sobre Google Workspace o usa de forma intensiva servicios de Google, comprueba qué integración concreta ofrece Gemini para vuestra licencia y país.
- Si vas a conectar datos internos o herramientas que ejecutan acciones, deja de hablar solo de “chat” y empieza a hablar de accesos, trazabilidad, límites y revisión humana.
ChatGPT: útil cuando necesitas un entorno generalista
ChatGPT es el producto conversacional de OpenAI. En la práctica, muchas empresas lo prueban primero para redacción, síntesis, ideación, análisis de archivos y preparación de borradores. Ese punto de partida es razonable, pero no convierte una cuenta individual en una política de empresa.
La prueba útil no es pedirle que escriba un texto bonito. Es darle una tarea repetible y medible: transformar una nota de reunión en un borrador de propuesta, convertir incidencias en categorías o resumir documentación que ya es pública o está autorizada para el piloto. Después mide el tiempo que ahorra y las correcciones que sigue necesitando una persona.
OpenAI publica los cambios de ChatGPT en sus notas de versión oficiales. Revísalas antes de fijar un procedimiento interno: la disponibilidad de modelos y funciones depende del plan, la región y la fecha.
Claude: conversación larga, documentos y trabajo que exige contexto
Claude es la familia de modelos de Anthropic. Su documentación actual describe capacidades de texto e imagen, uso de herramientas, trabajo multilingüe y ventanas de contexto que varían según el modelo. Eso puede ser relevante cuando el equipo necesita analizar documentación extensa, mantener una conversación de trabajo con bastante contexto o construir un flujo con herramientas.
Pero “más contexto” no equivale a “respuesta correcta”. En un piloto de documentación interna hay que comprobar tres cosas: que el material enviado esté permitido, que las citas o referencias se puedan revisar y que el resultado no se use como decisión final sin una persona responsable.
La documentación de modelos de Anthropic distingue modelos, capacidades y límites. Es una fuente mejor que cualquier comparativa estática, porque el catálogo cambia rápido.
Copilot: el nombre importa menos que el lugar donde trabaja
Copilot puede significar cosas distintas según el entorno. GitHub Copilot se orienta al trabajo de desarrollo: sugerencias en el editor, chat, revisión de código y flujos de agentes. Microsoft también documenta productos Copilot para otros entornos de trabajo. Antes de contratar o habilitar nada, concreta cuál necesitas.
Para un equipo de desarrollo, el piloto puede consistir en una tarea acotada: explicar una parte del repositorio, preparar pruebas para una función concreta o revisar una pull request. La métrica no debe ser el número de líneas generadas. Cuenta revisiones, incidencias, tiempo de preparación y cambios que el equipo ha decidido no aceptar.
La documentación de GitHub Copilot muestra que el producto cubre IDE, GitHub, CLI, agentes y distintas opciones de configuración. Esa amplitud es precisamente la razón para no hablar de Copilot como si fuese un único modelo.
Gemini: mira primero el ecosistema Google que ya tienes
Gemini se integra con productos y servicios de Google. Su ayuda oficial indica que la aplicación puede trabajar con texto, voz, imágenes y cámara, y que puede usar aplicaciones conectadas como Google Workspace o YouTube Music, dependiendo de la configuración. Para una empresa que ya centraliza documentos, correo y calendario en Google, esa cercanía puede ser más importante que una comparación abstracta de respuestas.
Aquí conviene hacer una comprobación muy concreta con IT o sistemas: qué licencia tenéis, qué conectores están activos, qué datos puede consultar Gemini y qué políticas se aplican a cuentas de trabajo. No lo des por supuesto porque una función aparezca en una demo o en una cuenta personal.
Google mantiene la información de disponibilidad y funciones en su ayuda oficial de Gemini. La disponibilidad puede cambiar por país, idioma, dispositivo y plan.
Una forma sencilla de elegir: cuatro preguntas antes de abrir una demo
1. ¿Qué tarea se repetirá cada semana?
“Usar IA” no es una tarea. “Preparar el primer borrador de respuestas a 30 consultas de soporte a la semana” sí lo es. Cuanto más concreta sea la tarea, más fácil será comparar herramientas y detectar si el resultado ahorra trabajo o solo lo desplaza.
2. ¿Qué datos puede ver durante el piloto?
Empieza con información pública, ficticia o previamente autorizada. Si el caso exige contratos, datos de clientes, nóminas, código privado o información sensible, la conversación pasa a ser de seguridad, contrato, configuración y gobierno del dato. No basta con elegir el modelo que ha dado una respuesta más convincente.
3. ¿Dónde trabaja ya el equipo?
Una herramienta muy capaz puede fracasar si obliga a copiar y pegar entre cinco sistemas. Si la tarea vive en un repositorio, revisa el ecosistema de desarrollo. Si vive en documentos y correo, mira el entorno de colaboración que ya usa la empresa. La integración no sustituye a la evaluación, pero reduce fricción.
4. ¿Cómo se revisa y mide el resultado?
Define antes de empezar quién valida, qué errores son inaceptables y qué métrica decidirá si el piloto continúa. Puede ser tiempo de preparación, porcentaje de borradores aprovechables, errores detectados o plazo de respuesta. Sin esa medida, la demo siempre parece mejor de lo que es.
No elijas por una captura: haz un piloto corto y comparable
Un piloto serio no necesita ser grande. Selecciona una tarea, prepara de 20 a 50 ejemplos representativos, establece qué datos están permitidos y prueba dos opciones con el mismo criterio. Guarda los resultados, las correcciones y los casos en los que cada asistente falla.
Al final tendrás una decisión más útil que “este modelo parece más listo”: sabrás cuál encaja con vuestro trabajo, qué controles necesita y si compensa integrarlo. A veces el resultado será elegir una plataforma. Otras veces será no automatizar todavía. Ambas conclusiones pueden ahorrar dinero.
Fuentes consultadas
- Notas de versión de ChatGPT, OpenAI.
- Modelos de Claude, Anthropic.
- About GitHub Copilot, GitHub Docs.
- Ayuda de las aplicaciones Gemini, Google.
Las funciones, modelos, planes y condiciones de uso cambian. Antes de implantar una de estas herramientas con datos internos, revisa la documentación del producto y las condiciones aplicables a vuestra cuenta.