Opus 5.5 ante METR: avances y límites

1. Hechos del caso y alcance de esta lectura

Antes de incorporar una herramienta al trabajo, conviene acordar qué resultado se aceptará y quién podrá comprobarlo. Una demostración aislada deja preguntas abiertas sobre el esfuerzo de revisión y las correcciones. Esta guía propone diseñar una comparación propia, conservar la evidencia y decidir con criterios definidos antes de ejecutar.

METR publicó el 22/09/2026 una evaluación preliminar: Opus 5.5 mostró avances incrementales frente a Fable 5.1; juzgó improbable automatizar toda I+D. Accedió por API diez días hábiles y probó cinco tareas. No evaluó alineamiento ni umbrales de política. Acuerdo no remunerado: Anthropic pudo revisar y editar; METR aprobó el texto final. No informa regiones ni disponibilidad pública actual. Fuente primaria: METR.

2. Empieza por la decisión que quieres tomar

Un piloto sirve si resuelve una decisión, no si produce una demostración vistosa. Escribe qué cambiaría si el resultado fuera aceptable: incorporar una etapa de borrador, revisar más fuentes o asistir una operación interna. Elige una unidad de trabajo con entrada y entrega reconocibles. Delimita qué no puede hacer el sistema: decidir, enviar, modificar recursos compartidos o tocar datos sensibles.

3. Construye una comparación justa

Compara con el proceso habitual: misma tarea, ejemplos equivalentes, regla de aceptación y nivel de apoyo humano. Si cambian los casos o las reglas durante la prueba, la comparación pierde valor. Registra procedimiento, insumos y revisión; conserva por qué cada salida se aceptó, corrigió o descartó, sin exponer datos internos.

Un caso ayuda a ver la diferencia: un borrador breve puede llegar antes y, aun así, exigir más comprobación de citas que el documento habitual. Otro puede tardar lo mismo, pero dejar referencias fáciles de revisar y menos correcciones. Son posibilidades de diseño, no resultados observados. Una comparación útil conserva ambas etapas: producir y aceptar. Si sólo se cronometra la primera, el equipo puede trasladar trabajo a quien revisa y confundir ese traslado con una mejora.

4. Propuesta editorial para tu equipo

Completa esta ficha antes de ejecutar. No hay valores precargados: acuerda criterios con el equipo y registra mediciones reales. Si falta un dato, déjalo como no disponible.

5. Calidad antes que rapidez

Define “aceptable” para el entregable. En una síntesis de investigación, la rúbrica podría exigir que las afirmaciones importantes tengan fuentes rastreables y que las discrepancias queden visibles. En una tarea técnica, podría requerir que otra persona reproduzca el resultado. Son criterios que el equipo debe adaptar, no una escala universal.

Separa defectos corregibles de fallos que invalidan el trabajo. Una buena calificación promedio no compensa una cita inexistente ni un cálculo que nadie puede verificar. Registra las causas de corrección y aplica la misma regla de aceptación a la vía habitual y a la asistida.

6. Calcula el coste del trabajo aceptado

Compara el coste por resultado que el equipo acepta, no una tarifa aislada del modelo. Suma consumo del servicio, preparación, revisión humana, correcciones, repeticiones e integración que la tarea realmente necesite. Aplica el mismo alcance al proceso actual.

Mide el tiempo y gasto observados. Si no sabes cuánto tomó verificar una salida, anótalo como no disponible; no lo presentes como ahorro. Tampoco extrapoles una prueba acotada a un mes de trabajo que no se midió.

7. Haz que la revisión deje rastro

Nombra a quien valida el resultado y acuerda la evidencia que necesita. Para un trabajo factual, esa persona debe poder volver a las fuentes y comprobar que sostienen lo escrito. Conserva salida, cambios humanos y motivo de cada corrección: así se ve si la herramienta reduce una tarea o traslada el esfuerzo a una revisión más compleja.

Distingue los usos internos de los que llegan a otras personas. Si el equipo no puede reconstruir de dónde sale una afirmación o quién aprobó el resultado, no lo envíes fuera ni lo uses para cambiar datos compartidos.

8. Acuerda cuándo parar o ampliar

Define condiciones de detención antes de mirar resultados: una falla de privacidad, una afirmación sin evidencia, una carga de corrección inaceptable o falta de una persona revisora. El umbral depende del riesgo y del coste de la tarea; no lo copies de otro equipo.

Amplía solo si la comparación puede repetirse, la calidad cumple la rúbrica y el coste total tiene sentido para la decisión original. Si una dimensión mejora y otra no, deja por escrito qué uso limitado sí se justifica y qué control permanece. Si la evidencia es insuficiente, mide mejor o mantén el proceso actual.

9. Cierra con una decisión verificable

El informe interno del piloto debe permitir que otra persona revise el criterio: tarea, ejemplos usados, regla de aceptación, calidad observada, coste total, trabajo de revisión y fallos. Indica también qué quedó sin medir. La decisión puede ser continuar con alcance limitado, cambiar el diseño o detenerse; registra el responsable y la condición para volver a evaluarla, con fecha acordada.

Un piloto no constituye por sí mismo una razón para ampliar el uso. La razón está en la evidencia que el equipo pudo comprobar y en la decisión concreta que esa evidencia permite tomar.