{"content_id":"ardq66qm2e","slug":"claude-opus-5-verification-and-migration-guide","locale":"es","schema_type":"TechArticle","category":"how_to","category_name":"Cómo hacer","title":"Cómo revisar prompts y arneses antes de migrar a Claude Opus 5","summary":"Distingue las características de Claude Opus 5 que afirma el material proporcionado de la información verificable y explica cómo rediseñar los prompts, los arneses y los sistemas de evaluación al adoptar un modelo de nueva generación. La disponibilidad, el precio y la denominación del modelo deben comprobarse siempre en la lista oficial de modelos y la tabla de precios de Anthropic.","author":{"name":"Equipo editorial de Injoys","url":"https://injoys.com/ko/about"},"key_points":["Las fechas de lanzamiento, los precios y el rendimiento de Claude Opus 5, Fable 5 y Sonnet 5 que aparecen en el material proporcionado deben verificarse de forma independiente con fuentes oficiales antes de utilizarse.","En lugar de copiar sin cambios los prompts existentes para un nuevo modelo, deben volver a medirse la calidad, el coste y la latencia con datos de trabajo reales.","Las instrucciones de verificación redundantes y las llamadas ilimitadas a subagentes pueden aumentar el coste y el tiempo de ejecución sin mejorar los resultados.","Separar las instrucciones del sistema, las reglas del proyecto, las Skill que se cargan cuando son necesarias y las referencias técnicas facilita la gestión del contexto.","Las evaluaciones propias que reflejan las tareas reales de la organización y el coste de los fallos ofrecen una base más directa para elegir un modelo que las clasificaciones de benchmarks."],"content_markdown":"El material proporcionado presenta Claude Opus 5 como un modelo adaptado al trabajo cotidiano empresarial y con agentes, y sostiene que, con la nueva generación de Claude, es necesario rediseñar los prompts y los arneses existentes. Sin embargo, **las fechas de lanzamiento, los precios y el rendimiento de Claude Opus 5, Fable 5 y Sonnet 5, así como las declaraciones de socios mencionadas en el material, no se han verificado de manera independiente únicamente con la información proporcionada en este artículo.** En particular, primero debe comprobarse en la lista oficial de modelos si `Fable` es una denominación oficial de un modelo de Anthropic.\n\nPor lo tanto, en lugar de repetir esa información de lanzamiento como un hecho confirmado, este documento organiza por separado los aspectos que deben verificarse en la documentación oficial y los procedimientos de validación que pueden aplicarse a una migración real de modelos.\n\n## Información de lanzamiento que debe verificarse primero\n\nAntes de aplicar un modelo nuevo a la API, la aplicación Claude o Claude Code, deben contrastarse los siguientes aspectos con la documentación oficial de Anthropic y con la pantalla de selección de modelos del servicio utilizado.\n\n| Aspecto que verificar | Afirmación del material proporcionado | Verificación necesaria |\n|---|---|---|\n| Nombre del modelo | Claude Opus 5, Fable 5, Sonnet 5 | Nombre exacto del producto e ID del modelo en la lista oficial de modelos |\n| Fecha de lanzamiento | 9 de junio, 30 de junio y 24 de julio, respectivamente | Año y fecha del anuncio oficial y del historial de cambios |\n| Precio de Opus 5 | 5 dólares de entrada y 25 dólares de salida por cada millón de tokens | Tarifas oficiales de la API y precios separados para lotes, caché y contexto largo |\n| Modelo predeterminado del producto | Nuevo modelo predeterminado de Claude Max | Disponibilidad según región, plan y cliente |\n| Función de cada modelo | División entre trabajo autónomo de larga duración, trabajo cotidiano y tareas ligeras | Descripción oficial de los modelos y resultados de evaluaciones con trabajo real |\n| Mejora del rendimiento | Mejora de un porcentaje específico respecto al modelo anterior | Tareas de evaluación, tamaño de la muestra, criterios de medición y texto original de los socios |\n\nSi el nombre o el precio de un modelo no aparece en la documentación oficial, no debe utilizarse para configurar la API ni calcular presupuestos. Si se utiliza un proveedor de nube o un servicio de reventa, el ID del modelo, el precio y la fecha de disponibilidad también podrían diferir de los de la API directa de Anthropic.\n\n## Criterios de decisión que deben cambiar al migrar de modelo\n\n### 1. Medir la eficiencia por tarea, no solo el máximo rendimiento\n\nProcesar todas las solicitudes con el modelo más caro puede elevar rápidamente los costes cuando un agente llama repetidamente a varias herramientas y subagentes. El modelo no debe elegirse por su nombre o categoría, sino teniendo en cuenta conjuntamente los siguientes indicadores.\n\n- **Tasa de éxito:** porcentaje de tareas que cumplen los requisitos sin que una persona tenga que corregirlas\n- **Coste total:** coste que incluye no solo la solicitud inicial, sino también los reintentos, las llamadas a herramientas y las llamadas a subagentes\n- **Tiempo de finalización:** tiempo que incluye la espera y el tiempo de revisión y corrección de una persona\n- **Coste de los fallos:** impacto causado por fallos como vulnerabilidades de seguridad, despliegues incorrectos o análisis incompletos\n- **Consistencia:** grado de variación de los resultados al repetir el mismo tipo de tarea\n\nEl coste por tarea no debe juzgarse únicamente por el precio unitario de los tokens. Conceptualmente, puede calcularse de la siguiente manera.\n\n`Coste total por tarea = coste del modelo principal + coste de los subagentes + coste de las herramientas + coste de los reintentos + coste de la revisión humana`\n\n### 2. Separar los benchmarks públicos de las evaluaciones propias\n\nLos benchmarks públicos constituyen un punto de partida para comparar las características generales de los modelos, pero no garantizan el éxito en una base de código, un formato documental o unas reglas operativas específicos. Las organizaciones deben crear un conjunto propio de evaluación mediante la anonimización de tareas reales.\n\nUn buen conjunto de evaluación incluye conjuntamente los siguientes casos.\n\n- Tareas representativas que deben completarse con normalidad\n- Casos límite en los que el modelo se equivoca con frecuencia\n- Tareas con requisitos ambiguos que exigen preguntas adicionales\n- Tareas que requieren llamadas a herramientas o la consulta de fuentes externas\n- Tareas de alto riesgo en las que debe detenerse la ejecución o solicitarse la aprobación de una persona\n- Tareas en las que debe guardarse y recuperarse el estado durante una ejecución prolongada\n\nPara que la comparación sea posible, deben aplicarse a cada modelo las mismas entradas, herramientas, límites de tiempo y criterios de éxito. Es más seguro registrar la tasa de éxito y la distribución de costes obtenidas tras varias repeticiones que basarse en uno o dos resultados llamativos.\n\n### 3. Evaluar el modelo y el arnés como un único sistema\n\nUn **arnés (harness)** es el entorno de ejecución que rodea al modelo. Incluye el prompt del sistema, las instrucciones del proyecto, la búsqueda, la memoria, las herramientas, las Skill, los subagentes, la gestión de permisos y la lógica de validación y reintentos.\n\nIncluso un mismo modelo puede producir resultados diferentes según el arnés. Por ejemplo, si el propio modelo crea y ejecuta pruebas y el arnés también impone la misma validación, puede duplicarse el trabajo. Por el contrario, resulta peligroso dejar al criterio autónomo del modelo incluso las etapas que requieren controles deterministas, como la aprobación de despliegues o las comprobaciones de seguridad.\n\nEl principio fundamental es **distinguir entre el razonamiento que el modelo realiza bien y los controles que el sistema debe garantizar obligatoriamente**.\n\n## 6 aspectos que revisar en los prompts y el arnés\n\n### 1. Eliminar de manera experimental las instrucciones duplicadas de validación y comprobación\n\nEliminar incondicionalmente frases como `Después de terminar, asegúrate de comprobarlo de nuevo` no es necesariamente la solución correcta. Primero debe rastrearse si las validaciones que realiza espontáneamente el modelo se solapan con las etapas de validación del arnés.\n\n- Si la revisión del propio modelo solo se repite sin mejorar la calidad, se reduce el prompt.\n- Las comprobaciones que pueden automatizarse, como las pruebas, la validación de esquemas y el análisis estático, se mantienen en el arnés.\n- La aprobación de tareas de alto riesgo, como pagos, despliegues o eliminación de datos, no se sustituye por la validación del propio modelo.\n\n### 2. Definir las condiciones y el límite máximo de llamadas a subagentes\n\nLos subagentes son útiles para realizar investigaciones en paralelo o separar áreas especializadas, pero delegarles incluso tareas pequeñas incrementa los costes y la latencia. Pueden especificarse políticas como las siguientes.\n\n- Utilizar subagentes únicamente para tareas que puedan dividirse de manera independiente.\n- Limitar el número de subagentes que pueden ejecutarse simultáneamente en una solicitud.\n- Asignar a cada subagente un resultado esperado y unas condiciones de finalización claros.\n- Evitar que varios agentes exploren de manera redundante el mismo material.\n- Solicitar la aprobación de una persona si el coste o el tiempo estimados superan el umbral.\n\n### 3. Convertir las prohibiciones detalladas en criterios de decisión\n\nLas listas extensas de prohibiciones pueden entrar en conflicto entre sí o no contemplar situaciones nuevas. En ámbitos de bajo riesgo, como el estilo, puede dejarse que el modelo decida tras interpretar el contexto circundante.\n\n- Prescriptiva: `Nunca escribas docstrings de varios párrafos.`\n- Delegación del criterio: `Sigue la densidad de comentarios, el formato de los docstrings, la nomenclatura y los modismos del código existente.`\n\nNo obstante, las reglas cuyo incumplimiento tenga un coste elevado, como las relativas al tratamiento de datos personales, la seguridad o las obligaciones legales, deben mantenerse mediante restricciones explícitas y comprobaciones programáticas.\n\n### 4. Especificar directamente la longitud de la respuesta y el formato de salida\n\nLos recursos utilizados para razonar y la longitud de la respuesta visible para el usuario no son el mismo concepto. Aunque el cliente ofrezca una opción de intensidad de razonamiento como `effort` u otra similar, si se necesita una respuesta breve deben definirse por separado las condiciones de salida.\n\nEstos son algunos ejemplos.\n\n- `Escribe primero la conclusión y resume los fundamentos en un máximo de tres puntos.`\n- `Redacta la respuesta final con un máximo de 500 caracteres.`\n- `Devuelve únicamente un objeto JSON válido, sin explicaciones.`\n- `Informa únicamente de los archivos modificados, los motivos principales y los riesgos restantes.`\n\n### 5. Recalibrar la intensidad de razonamiento con tareas reales\n\nLa intensidad de razonamiento o el valor predeterminado de effort utilizado con el modelo anterior no debe aplicarse sin cambios al modelo nuevo. La curva de costes se mide comenzando con una configuración baja y aumentándola únicamente cuando la calidad sea insuficiente.\n\n| Tipo de tarea | Configuración inicial | Condición para aumentarla |\n|---|---|---|\n| Clasificación y conversión de formatos | Empezar con una configuración baja | Cuando se repitan errores de esquema u omisiones |\n| Modificación general de documentos y código | Comparar valores intermedios | Cuando se omitan dependencias entre varios archivos |\n| Depuración compleja | Probar un nivel medio o superior | Cuando sean insuficientes el análisis de causas y la tasa de éxito de la validación |\n| Trabajo de agentes de larga duración | Medir por etapas | Tramos de alta dificultad que requieran replanificación y recuperación |\n\nDado que el nombre exacto de las opciones y su compatibilidad pueden variar según la versión de la API y el producto, debe consultarse la documentación oficial.\n\n### 6. Dividir el contexto por función y revelarlo progresivamente\n\nSi todas las instrucciones se incluyen en un único prompt del sistema o archivo `CLAUDE.md`, cada solicitud puede incorporar también información irrelevante. Resulta práctica una estructura jerárquica como la siguiente.\n\n1. **Instrucciones del sistema y del producto:** reglas siempre necesarias, como la función, los límites de seguridad y el contrato de salida\n2. **Instrucciones ligeras del proyecto:** comandos de compilación, estructura de directorios y métodos de trabajo comunes\n3. **Skill que se cargan cuando son necesarias:** procedimientos condicionales, como despliegues, cambios en bases de datos o frameworks específicos\n4. **Referencias técnicas:** esquemas de API, ejemplos de código, documentos de diseño y especificaciones que puedan someterse a pruebas\n\nEsto puede denominarse **revelación progresiva**. Debe permitirse que el modelo busque o cargue los materiales necesarios para la etapa actual, pero es preciso registrar qué materiales ha utilizado para garantizar la reproducibilidad y la auditabilidad.\n\n## Procedimiento de migración recomendado\n\n### Paso 1: Fijar el estado actual\n\nSe guardan los prompts, las versiones de las herramientas, la tasa de éxito, el uso de tokens, la latencia y los casos de fallo del modelo existente. Sin una línea base, resulta difícil determinar si el modelo nuevo supone realmente una mejora.\n\n### Paso 2: Verificar la información y los permisos del modelo\n\nSe comprueban el ID oficial del modelo, el precio, el límite de contexto, la compatibilidad con herramientas y la política de conservación de datos. En el entorno de pruebas, se limitan los permisos de escritura, eliminación y despliegue.\n\n### Paso 3: Probar sin cambios el arnés existente\n\nAl principio no debe cambiarse todo a la vez. Si solo se sustituye el modelo y se compara con la línea base, puede aislarse el impacto del cambio de modelo.\n\n### Paso 4: Eliminar una por una las instrucciones duplicadas\n\nSe eliminan de uno en uno los distintos tipos de instrucciones de validación, reglas de estilo prolijas, ejemplos innecesarios y referencias que se inyectan siempre. Tras cada cambio, se vuelven a medir la calidad y el coste.\n\n### Paso 5: Crear una política de enrutamiento\n\nEl modelo se selecciona según la dificultad del trabajo, el riesgo, el contexto previsto y el límite de tiempo. Las funciones por modelo propuestas en el material proporcionado deben probarse como hipótesis después de confirmar los nombres oficiales y el rendimiento, y no deben adoptarse sin más como política operativa.\n\n### Paso 6: Empezar el despliegue con tráfico limitado\n\nPrimero se aplica a algunos usuarios o a tareas sin riesgo. El alcance se amplía después de observar la tasa de fallos, los reintentos, el número de subagentes, los errores de herramientas y el tiempo de corrección humana.\n\n## Lista de comprobación operativa\n\n- [ ] Se han confirmado el nombre oficial del modelo y su ID de modelo de API.\n- [ ] Se han confirmado las tarifas realmente aplicables de entrada, salida, caché, lotes y otros conceptos.\n- [ ] Existe un conjunto propio de evaluación compuesto por tareas reales.\n- [ ] Las etapas de validación del modelo y del arnés no se duplican.\n- [ ] Existen criterios para llamar a subagentes, un límite de ejecuciones simultáneas y un presupuesto máximo.\n- [ ] Se han especificado la longitud de la respuesta y el esquema de salida.\n- [ ] Se han comparado la calidad, el coste y la latencia según la intensidad de razonamiento.\n- [ ] Se mantienen comprobaciones deterministas y la aprobación de una persona para las tareas de alto riesgo.\n- [ ] El contexto está dividido entre instrucciones permanentes, Skill y referencias.\n- [ ] Están preparados el modelo y la configuración anteriores para una reversión.\n\n## Conclusión\n\nLa clave de la migración a un modelo nuevo no consiste en acortar incondicionalmente los prompts ni en ampliar incondicionalmente la autonomía. Lo esencial es **comprobar primero la información oficial del producto y volver a dividir las funciones del modelo y del arnés mediante evaluaciones con trabajo real**.\n\nLas cifras y denominaciones relativas a Claude Opus 5 incluidas en el material proporcionado deben tratarse como información provisional hasta que se confirmen sus fuentes oficiales. Sin embargo, eliminar validaciones duplicadas, limitar los subagentes, establecer contratos de salida claros, revelar progresivamente el contexto y aplicar un enrutamiento basado en evaluaciones propias son principios de migración aplicables con independencia de la generación del modelo.","content_html":"\u003cp\u003eEl material proporcionado presenta Claude Opus 5 como un modelo adaptado al trabajo cotidiano empresarial y con agentes, y sostiene que, con la nueva generación de Claude, es necesario rediseñar los prompts y los arneses existentes. Sin embargo, \u003cstrong\u003elas fechas de lanzamiento, los precios y el rendimiento de Claude Opus 5, Fable 5 y Sonnet 5, así como las declaraciones de socios mencionadas en el material, no se han verificado de manera independiente únicamente con la información proporcionada en este artículo.\u003c/strong\u003e En particular, primero debe comprobarse en la lista oficial de modelos si \u003ccode\u003eFable\u003c/code\u003e es una denominación oficial de un modelo de Anthropic.\u003c/p\u003e\n\u003cp\u003ePor lo tanto, en lugar de repetir esa información de lanzamiento como un hecho confirmado, este documento organiza por separado los aspectos que deben verificarse en la documentación oficial y los procedimientos de validación que pueden aplicarse a una migración real de modelos.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#informaci%C3%B3n-de-lanzamiento-que-debe-verificarse-primero\" class=\"anchor\" id=\"información-de-lanzamiento-que-debe-verificarse-primero\"\u003e\u003c/a\u003eInformación de lanzamiento que debe verificarse primero\u003c/h2\u003e\n\u003cp\u003eAntes de aplicar un modelo nuevo a la API, la aplicación Claude o Claude Code, deben contrastarse los siguientes aspectos con la documentación oficial de Anthropic y con la pantalla de selección de modelos del servicio utilizado.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eAspecto que verificar\u003c/th\u003e\n\u003cth\u003eAfirmación del material proporcionado\u003c/th\u003e\n\u003cth\u003eVerificación necesaria\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aspecto que verificar\"\u003eNombre del modelo\u003c/td\u003e\n\u003ctd data-label=\"Afirmación del material proporcionado\"\u003eClaude Opus 5, Fable 5, Sonnet 5\u003c/td\u003e\n\u003ctd data-label=\"Verificación necesaria\"\u003eNombre exacto del producto e ID del modelo en la lista oficial de modelos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aspecto que verificar\"\u003eFecha de lanzamiento\u003c/td\u003e\n\u003ctd data-label=\"Afirmación del material proporcionado\"\u003e9 de junio, 30 de junio y 24 de julio, respectivamente\u003c/td\u003e\n\u003ctd data-label=\"Verificación necesaria\"\u003eAño y fecha del anuncio oficial y del historial de cambios\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aspecto que verificar\"\u003ePrecio de Opus 5\u003c/td\u003e\n\u003ctd data-label=\"Afirmación del material proporcionado\"\u003e5 dólares de entrada y 25 dólares de salida por cada millón de tokens\u003c/td\u003e\n\u003ctd data-label=\"Verificación necesaria\"\u003eTarifas oficiales de la API y precios separados para lotes, caché y contexto largo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aspecto que verificar\"\u003eModelo predeterminado del producto\u003c/td\u003e\n\u003ctd data-label=\"Afirmación del material proporcionado\"\u003eNuevo modelo predeterminado de Claude Max\u003c/td\u003e\n\u003ctd data-label=\"Verificación necesaria\"\u003eDisponibilidad según región, plan y cliente\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aspecto que verificar\"\u003eFunción de cada modelo\u003c/td\u003e\n\u003ctd data-label=\"Afirmación del material proporcionado\"\u003eDivisión entre trabajo autónomo de larga duración, trabajo cotidiano y tareas ligeras\u003c/td\u003e\n\u003ctd data-label=\"Verificación necesaria\"\u003eDescripción oficial de los modelos y resultados de evaluaciones con trabajo real\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aspecto que verificar\"\u003eMejora del rendimiento\u003c/td\u003e\n\u003ctd data-label=\"Afirmación del material proporcionado\"\u003eMejora de un porcentaje específico respecto al modelo anterior\u003c/td\u003e\n\u003ctd data-label=\"Verificación necesaria\"\u003eTareas de evaluación, tamaño de la muestra, criterios de medición y texto original de los socios\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eSi el nombre o el precio de un modelo no aparece en la documentación oficial, no debe utilizarse para configurar la API ni calcular presupuestos. Si se utiliza un proveedor de nube o un servicio de reventa, el ID del modelo, el precio y la fecha de disponibilidad también podrían diferir de los de la API directa de Anthropic.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#criterios-de-decisi%C3%B3n-que-deben-cambiar-al-migrar-de-modelo\" class=\"anchor\" id=\"criterios-de-decisión-que-deben-cambiar-al-migrar-de-modelo\"\u003e\u003c/a\u003eCriterios de decisión que deben cambiar al migrar de modelo\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-medir-la-eficiencia-por-tarea-no-solo-el-m%C3%A1ximo-rendimiento\" class=\"anchor\" id=\"1-medir-la-eficiencia-por-tarea-no-solo-el-máximo-rendimiento\"\u003e\u003c/a\u003e1. Medir la eficiencia por tarea, no solo el máximo rendimiento\u003c/h3\u003e\n\u003cp\u003eProcesar todas las solicitudes con el modelo más caro puede elevar rápidamente los costes cuando un agente llama repetidamente a varias herramientas y subagentes. El modelo no debe elegirse por su nombre o categoría, sino teniendo en cuenta conjuntamente los siguientes indicadores.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eTasa de éxito:\u003c/strong\u003e porcentaje de tareas que cumplen los requisitos sin que una persona tenga que corregirlas\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCoste total:\u003c/strong\u003e coste que incluye no solo la solicitud inicial, sino también los reintentos, las llamadas a herramientas y las llamadas a subagentes\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTiempo de finalización:\u003c/strong\u003e tiempo que incluye la espera y el tiempo de revisión y corrección de una persona\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCoste de los fallos:\u003c/strong\u003e impacto causado por fallos como vulnerabilidades de seguridad, despliegues incorrectos o análisis incompletos\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eConsistencia:\u003c/strong\u003e grado de variación de los resultados al repetir el mismo tipo de tarea\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEl coste por tarea no debe juzgarse únicamente por el precio unitario de los tokens. Conceptualmente, puede calcularse de la siguiente manera.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eCoste total por tarea = coste del modelo principal + coste de los subagentes + coste de las herramientas + coste de los reintentos + coste de la revisión humana\u003c/code\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-separar-los-benchmarks-p%C3%BAblicos-de-las-evaluaciones-propias\" class=\"anchor\" id=\"2-separar-los-benchmarks-públicos-de-las-evaluaciones-propias\"\u003e\u003c/a\u003e2. Separar los benchmarks públicos de las evaluaciones propias\u003c/h3\u003e\n\u003cp\u003eLos benchmarks públicos constituyen un punto de partida para comparar las características generales de los modelos, pero no garantizan el éxito en una base de código, un formato documental o unas reglas operativas específicos. Las organizaciones deben crear un conjunto propio de evaluación mediante la anonimización de tareas reales.\u003c/p\u003e\n\u003cp\u003eUn buen conjunto de evaluación incluye conjuntamente los siguientes casos.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTareas representativas que deben completarse con normalidad\u003c/li\u003e\n\u003cli\u003eCasos límite en los que el modelo se equivoca con frecuencia\u003c/li\u003e\n\u003cli\u003eTareas con requisitos ambiguos que exigen preguntas adicionales\u003c/li\u003e\n\u003cli\u003eTareas que requieren llamadas a herramientas o la consulta de fuentes externas\u003c/li\u003e\n\u003cli\u003eTareas de alto riesgo en las que debe detenerse la ejecución o solicitarse la aprobación de una persona\u003c/li\u003e\n\u003cli\u003eTareas en las que debe guardarse y recuperarse el estado durante una ejecución prolongada\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePara que la comparación sea posible, deben aplicarse a cada modelo las mismas entradas, herramientas, límites de tiempo y criterios de éxito. Es más seguro registrar la tasa de éxito y la distribución de costes obtenidas tras varias repeticiones que basarse en uno o dos resultados llamativos.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-evaluar-el-modelo-y-el-arn%C3%A9s-como-un-%C3%BAnico-sistema\" class=\"anchor\" id=\"3-evaluar-el-modelo-y-el-arnés-como-un-único-sistema\"\u003e\u003c/a\u003e3. Evaluar el modelo y el arnés como un único sistema\u003c/h3\u003e\n\u003cp\u003eUn \u003cstrong\u003earnés (harness)\u003c/strong\u003e es el entorno de ejecución que rodea al modelo. Incluye el prompt del sistema, las instrucciones del proyecto, la búsqueda, la memoria, las herramientas, las Skill, los subagentes, la gestión de permisos y la lógica de validación y reintentos.\u003c/p\u003e\n\u003cp\u003eIncluso un mismo modelo puede producir resultados diferentes según el arnés. Por ejemplo, si el propio modelo crea y ejecuta pruebas y el arnés también impone la misma validación, puede duplicarse el trabajo. Por el contrario, resulta peligroso dejar al criterio autónomo del modelo incluso las etapas que requieren controles deterministas, como la aprobación de despliegues o las comprobaciones de seguridad.\u003c/p\u003e\n\u003cp\u003eEl principio fundamental es \u003cstrong\u003edistinguir entre el razonamiento que el modelo realiza bien y los controles que el sistema debe garantizar obligatoriamente\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-aspectos-que-revisar-en-los-prompts-y-el-arn%C3%A9s\" class=\"anchor\" id=\"6-aspectos-que-revisar-en-los-prompts-y-el-arnés\"\u003e\u003c/a\u003e6 aspectos que revisar en los prompts y el arnés\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-eliminar-de-manera-experimental-las-instrucciones-duplicadas-de-validaci%C3%B3n-y-comprobaci%C3%B3n\" class=\"anchor\" id=\"1-eliminar-de-manera-experimental-las-instrucciones-duplicadas-de-validación-y-comprobación\"\u003e\u003c/a\u003e1. Eliminar de manera experimental las instrucciones duplicadas de validación y comprobación\u003c/h3\u003e\n\u003cp\u003eEliminar incondicionalmente frases como \u003ccode\u003eDespués de terminar, asegúrate de comprobarlo de nuevo\u003c/code\u003e no es necesariamente la solución correcta. Primero debe rastrearse si las validaciones que realiza espontáneamente el modelo se solapan con las etapas de validación del arnés.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSi la revisión del propio modelo solo se repite sin mejorar la calidad, se reduce el prompt.\u003c/li\u003e\n\u003cli\u003eLas comprobaciones que pueden automatizarse, como las pruebas, la validación de esquemas y el análisis estático, se mantienen en el arnés.\u003c/li\u003e\n\u003cli\u003eLa aprobación de tareas de alto riesgo, como pagos, despliegues o eliminación de datos, no se sustituye por la validación del propio modelo.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-definir-las-condiciones-y-el-l%C3%ADmite-m%C3%A1ximo-de-llamadas-a-subagentes\" class=\"anchor\" id=\"2-definir-las-condiciones-y-el-límite-máximo-de-llamadas-a-subagentes\"\u003e\u003c/a\u003e2. Definir las condiciones y el límite máximo de llamadas a subagentes\u003c/h3\u003e\n\u003cp\u003eLos subagentes son útiles para realizar investigaciones en paralelo o separar áreas especializadas, pero delegarles incluso tareas pequeñas incrementa los costes y la latencia. Pueden especificarse políticas como las siguientes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eUtilizar subagentes únicamente para tareas que puedan dividirse de manera independiente.\u003c/li\u003e\n\u003cli\u003eLimitar el número de subagentes que pueden ejecutarse simultáneamente en una solicitud.\u003c/li\u003e\n\u003cli\u003eAsignar a cada subagente un resultado esperado y unas condiciones de finalización claros.\u003c/li\u003e\n\u003cli\u003eEvitar que varios agentes exploren de manera redundante el mismo material.\u003c/li\u003e\n\u003cli\u003eSolicitar la aprobación de una persona si el coste o el tiempo estimados superan el umbral.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-convertir-las-prohibiciones-detalladas-en-criterios-de-decisi%C3%B3n\" class=\"anchor\" id=\"3-convertir-las-prohibiciones-detalladas-en-criterios-de-decisión\"\u003e\u003c/a\u003e3. Convertir las prohibiciones detalladas en criterios de decisión\u003c/h3\u003e\n\u003cp\u003eLas listas extensas de prohibiciones pueden entrar en conflicto entre sí o no contemplar situaciones nuevas. En ámbitos de bajo riesgo, como el estilo, puede dejarse que el modelo decida tras interpretar el contexto circundante.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePrescriptiva: \u003ccode\u003eNunca escribas docstrings de varios párrafos.\u003c/code\u003e\n\u003c/li\u003e\n\u003cli\u003eDelegación del criterio: \u003ccode\u003eSigue la densidad de comentarios, el formato de los docstrings, la nomenclatura y los modismos del código existente.\u003c/code\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNo obstante, las reglas cuyo incumplimiento tenga un coste elevado, como las relativas al tratamiento de datos personales, la seguridad o las obligaciones legales, deben mantenerse mediante restricciones explícitas y comprobaciones programáticas.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#4-especificar-directamente-la-longitud-de-la-respuesta-y-el-formato-de-salida\" class=\"anchor\" id=\"4-especificar-directamente-la-longitud-de-la-respuesta-y-el-formato-de-salida\"\u003e\u003c/a\u003e4. Especificar directamente la longitud de la respuesta y el formato de salida\u003c/h3\u003e\n\u003cp\u003eLos recursos utilizados para razonar y la longitud de la respuesta visible para el usuario no son el mismo concepto. Aunque el cliente ofrezca una opción de intensidad de razonamiento como \u003ccode\u003eeffort\u003c/code\u003e u otra similar, si se necesita una respuesta breve deben definirse por separado las condiciones de salida.\u003c/p\u003e\n\u003cp\u003eEstos son algunos ejemplos.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eEscribe primero la conclusión y resume los fundamentos en un máximo de tres puntos.\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eRedacta la respuesta final con un máximo de 500 caracteres.\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eDevuelve únicamente un objeto JSON válido, sin explicaciones.\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eInforma únicamente de los archivos modificados, los motivos principales y los riesgos restantes.\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#5-recalibrar-la-intensidad-de-razonamiento-con-tareas-reales\" class=\"anchor\" id=\"5-recalibrar-la-intensidad-de-razonamiento-con-tareas-reales\"\u003e\u003c/a\u003e5. Recalibrar la intensidad de razonamiento con tareas reales\u003c/h3\u003e\n\u003cp\u003eLa intensidad de razonamiento o el valor predeterminado de effort utilizado con el modelo anterior no debe aplicarse sin cambios al modelo nuevo. La curva de costes se mide comenzando con una configuración baja y aumentándola únicamente cuando la calidad sea insuficiente.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTipo de tarea\u003c/th\u003e\n\u003cth\u003eConfiguración inicial\u003c/th\u003e\n\u003cth\u003eCondición para aumentarla\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tipo de tarea\"\u003eClasificación y conversión de formatos\u003c/td\u003e\n\u003ctd data-label=\"Configuración inicial\"\u003eEmpezar con una configuración baja\u003c/td\u003e\n\u003ctd data-label=\"Condición para aumentarla\"\u003eCuando se repitan errores de esquema u omisiones\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tipo de tarea\"\u003eModificación general de documentos y código\u003c/td\u003e\n\u003ctd data-label=\"Configuración inicial\"\u003eComparar valores intermedios\u003c/td\u003e\n\u003ctd data-label=\"Condición para aumentarla\"\u003eCuando se omitan dependencias entre varios archivos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tipo de tarea\"\u003eDepuración compleja\u003c/td\u003e\n\u003ctd data-label=\"Configuración inicial\"\u003eProbar un nivel medio o superior\u003c/td\u003e\n\u003ctd data-label=\"Condición para aumentarla\"\u003eCuando sean insuficientes el análisis de causas y la tasa de éxito de la validación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tipo de tarea\"\u003eTrabajo de agentes de larga duración\u003c/td\u003e\n\u003ctd data-label=\"Configuración inicial\"\u003eMedir por etapas\u003c/td\u003e\n\u003ctd data-label=\"Condición para aumentarla\"\u003eTramos de alta dificultad que requieran replanificación y recuperación\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDado que el nombre exacto de las opciones y su compatibilidad pueden variar según la versión de la API y el producto, debe consultarse la documentación oficial.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#6-dividir-el-contexto-por-funci%C3%B3n-y-revelarlo-progresivamente\" class=\"anchor\" id=\"6-dividir-el-contexto-por-función-y-revelarlo-progresivamente\"\u003e\u003c/a\u003e6. Dividir el contexto por función y revelarlo progresivamente\u003c/h3\u003e\n\u003cp\u003eSi todas las instrucciones se incluyen en un único prompt del sistema o archivo \u003ccode\u003eCLAUDE.md\u003c/code\u003e, cada solicitud puede incorporar también información irrelevante. Resulta práctica una estructura jerárquica como la siguiente.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eInstrucciones del sistema y del producto:\u003c/strong\u003e reglas siempre necesarias, como la función, los límites de seguridad y el contrato de salida\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eInstrucciones ligeras del proyecto:\u003c/strong\u003e comandos de compilación, estructura de directorios y métodos de trabajo comunes\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eSkill que se cargan cuando son necesarias:\u003c/strong\u003e procedimientos condicionales, como despliegues, cambios en bases de datos o frameworks específicos\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eReferencias técnicas:\u003c/strong\u003e esquemas de API, ejemplos de código, documentos de diseño y especificaciones que puedan someterse a pruebas\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eEsto puede denominarse \u003cstrong\u003erevelación progresiva\u003c/strong\u003e. Debe permitirse que el modelo busque o cargue los materiales necesarios para la etapa actual, pero es preciso registrar qué materiales ha utilizado para garantizar la reproducibilidad y la auditabilidad.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#procedimiento-de-migraci%C3%B3n-recomendado\" class=\"anchor\" id=\"procedimiento-de-migración-recomendado\"\u003e\u003c/a\u003eProcedimiento de migración recomendado\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#paso-1-fijar-el-estado-actual\" class=\"anchor\" id=\"paso-1-fijar-el-estado-actual\"\u003e\u003c/a\u003ePaso 1: Fijar el estado actual\u003c/h3\u003e\n\u003cp\u003eSe guardan los prompts, las versiones de las herramientas, la tasa de éxito, el uso de tokens, la latencia y los casos de fallo del modelo existente. Sin una línea base, resulta difícil determinar si el modelo nuevo supone realmente una mejora.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#paso-2-verificar-la-informaci%C3%B3n-y-los-permisos-del-modelo\" class=\"anchor\" id=\"paso-2-verificar-la-información-y-los-permisos-del-modelo\"\u003e\u003c/a\u003ePaso 2: Verificar la información y los permisos del modelo\u003c/h3\u003e\n\u003cp\u003eSe comprueban el ID oficial del modelo, el precio, el límite de contexto, la compatibilidad con herramientas y la política de conservación de datos. En el entorno de pruebas, se limitan los permisos de escritura, eliminación y despliegue.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#paso-3-probar-sin-cambios-el-arn%C3%A9s-existente\" class=\"anchor\" id=\"paso-3-probar-sin-cambios-el-arnés-existente\"\u003e\u003c/a\u003ePaso 3: Probar sin cambios el arnés existente\u003c/h3\u003e\n\u003cp\u003eAl principio no debe cambiarse todo a la vez. Si solo se sustituye el modelo y se compara con la línea base, puede aislarse el impacto del cambio de modelo.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#paso-4-eliminar-una-por-una-las-instrucciones-duplicadas\" class=\"anchor\" id=\"paso-4-eliminar-una-por-una-las-instrucciones-duplicadas\"\u003e\u003c/a\u003ePaso 4: Eliminar una por una las instrucciones duplicadas\u003c/h3\u003e\n\u003cp\u003eSe eliminan de uno en uno los distintos tipos de instrucciones de validación, reglas de estilo prolijas, ejemplos innecesarios y referencias que se inyectan siempre. Tras cada cambio, se vuelven a medir la calidad y el coste.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#paso-5-crear-una-pol%C3%ADtica-de-enrutamiento\" class=\"anchor\" id=\"paso-5-crear-una-política-de-enrutamiento\"\u003e\u003c/a\u003ePaso 5: Crear una política de enrutamiento\u003c/h3\u003e\n\u003cp\u003eEl modelo se selecciona según la dificultad del trabajo, el riesgo, el contexto previsto y el límite de tiempo. Las funciones por modelo propuestas en el material proporcionado deben probarse como hipótesis después de confirmar los nombres oficiales y el rendimiento, y no deben adoptarse sin más como política operativa.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#paso-6-empezar-el-despliegue-con-tr%C3%A1fico-limitado\" class=\"anchor\" id=\"paso-6-empezar-el-despliegue-con-tráfico-limitado\"\u003e\u003c/a\u003ePaso 6: Empezar el despliegue con tráfico limitado\u003c/h3\u003e\n\u003cp\u003ePrimero se aplica a algunos usuarios o a tareas sin riesgo. El alcance se amplía después de observar la tasa de fallos, los reintentos, el número de subagentes, los errores de herramientas y el tiempo de corrección humana.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-comprobaci%C3%B3n-operativa\" class=\"anchor\" id=\"lista-de-comprobación-operativa\"\u003e\u003c/a\u003eLista de comprobación operativa\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Se han confirmado el nombre oficial del modelo y su ID de modelo de API.\u003c/li\u003e\n\u003cli\u003e Se han confirmado las tarifas realmente aplicables de entrada, salida, caché, lotes y otros conceptos.\u003c/li\u003e\n\u003cli\u003e Existe un conjunto propio de evaluación compuesto por tareas reales.\u003c/li\u003e\n\u003cli\u003e Las etapas de validación del modelo y del arnés no se duplican.\u003c/li\u003e\n\u003cli\u003e Existen criterios para llamar a subagentes, un límite de ejecuciones simultáneas y un presupuesto máximo.\u003c/li\u003e\n\u003cli\u003e Se han especificado la longitud de la respuesta y el esquema de salida.\u003c/li\u003e\n\u003cli\u003e Se han comparado la calidad, el coste y la latencia según la intensidad de razonamiento.\u003c/li\u003e\n\u003cli\u003e Se mantienen comprobaciones deterministas y la aprobación de una persona para las tareas de alto riesgo.\u003c/li\u003e\n\u003cli\u003e El contexto está dividido entre instrucciones permanentes, Skill y referencias.\u003c/li\u003e\n\u003cli\u003e Están preparados el modelo y la configuración anteriores para una reversión.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusi%C3%B3n\" class=\"anchor\" id=\"conclusión\"\u003e\u003c/a\u003eConclusión\u003c/h2\u003e\n\u003cp\u003eLa clave de la migración a un modelo nuevo no consiste en acortar incondicionalmente los prompts ni en ampliar incondicionalmente la autonomía. Lo esencial es \u003cstrong\u003ecomprobar primero la información oficial del producto y volver a dividir las funciones del modelo y del arnés mediante evaluaciones con trabajo real\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLas cifras y denominaciones relativas a Claude Opus 5 incluidas en el material proporcionado deben tratarse como información provisional hasta que se confirmen sus fuentes oficiales. Sin embargo, eliminar validaciones duplicadas, limitar los subagentes, establecer contratos de salida claros, revelar progresivamente el contexto y aplicar un enrutamiento basado en evaluaciones propias son principios de migración aplicables con independencia de la generación del modelo.\u003c/p\u003e\n","tags":["Ingeniería de prompts","Agentes de IA","Anthropic","Claude","Evaluación de modelos"],"faqs":[{"question":"¿Claude Opus 5 es un modelo lanzado oficialmente?","answer":"Los materiales proporcionados indican una fecha de lanzamiento y un precio, pero esta información no se ha verificado de forma independiente únicamente con los datos incluidos en este artículo. Hasta que se confirmen el nombre exacto y el ID del modelo en la lista oficial de modelos de Anthropic, sus comunicados y la consola de la API, es más seguro no considerarla información definitiva sobre el producto."},{"question":"¿Fable 5 es un nombre de modelo oficial de Anthropic?","answer":"No se puede confirmar únicamente con los materiales proporcionados. Aunque los nombres de los productos sean similares, Anthropic puede utilizar distintos ID de modelo de API o denominaciones según el servicio, por lo que debe verificarse en la lista oficial de modelos si el nombre `Fable 5` existe realmente."},{"question":"Si cambio a un nuevo modelo de Claude, ¿debo eliminar todos los prompts existentes?","answer":"No. Primero debe realizarse una evaluación de referencia con la configuración existente y, después, eliminar una por una las instrucciones de verificación duplicadas o las reglas de estilo innecesarias, comparando la calidad y el coste. Deben mantenerse los controles que el sistema debe garantizar, como las comprobaciones de seguridad, la validación del esquema de salida y la aprobación del despliegue."},{"question":"¿Qué es un arnés?","answer":"Un arnés es el sistema que rodea a un modelo de IA para ejecutarlo en el trabajo real. Incluye el prompt del sistema, las instrucciones del proyecto, las herramientas, la búsqueda, la memoria, las Skill, los subagent, los reintentos, la gestión de permisos y los procedimientos de validación automática."},{"question":"¿Cómo debe limitarse el uso de subagent?","answer":"Deben utilizarse únicamente para tareas que puedan dividirse de forma independiente y deben establecerse límites máximos para el número de ejecuciones simultáneas y el número total de llamadas. Se pueden especificar los resultados que debe producir cada subagent y sus condiciones de finalización, y diseñar el sistema para que solicite la aprobación de una persona cuando el coste o el tiempo previstos superen un umbral."},{"question":"¿Por qué son más importantes las evaluaciones propias que los benchmarks públicos?","answer":"Los benchmarks públicos no reflejan exactamente la base de código, los formatos de los documentos, el entorno de herramientas ni el coste de los fallos de una organización. Para determinar qué modelo es adecuado para el entorno operativo, deben medirse la tasa de éxito, el coste total, el tiempo de finalización y la consistencia de los resultados utilizando casos de trabajo reales."},{"question":"Si el modelo cuenta con autovalidación, ¿se pueden eliminar las pruebas?","answer":"No. La autorrevisión del modelo es un recurso auxiliar y no sustituye las pruebas, la validación de esquemas, el análisis estático ni las políticas de seguridad. En particular, las tareas de alto riesgo, como el despliegue, los pagos y la eliminación de datos, requieren comprobaciones deterministas y la aprobación de una persona."},{"question":"Si se reduce el effort, ¿las respuestas también se acortan automáticamente?","answer":"No necesariamente. La intensidad del razonamiento y la longitud de la salida final pueden ser aspectos que se controlen por separado. Si se necesita una respuesta concisa, el formato de la respuesta, como el número de caracteres, el número de elementos o el esquema de salida, debe especificarse directamente en el prompt."}],"sources":[{"url":"https://docs.anthropic.com/en/docs/about-claude/models/overview","title":"Documentación de Anthropic: descripción general de los modelos","type":"source"},{"url":"https://www.anthropic.com/pricing","title":"Precios de Anthropic","type":"data_point"},{"url":"https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview","title":"Documentación de Anthropic: descripción general de la ingeniería de prompts","type":"source"},{"url":"https://docs.anthropic.com/en/docs/claude-code/memory","title":"Documentación de Anthropic: memoria de Claude Code","type":"source"}],"images":[{"id":324,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--f44d725b558668593419631e29f28834deb66ecc/ai-95ae89bc.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"체크 항목과 경고 장벽 사이에서 AI 큐브를 돋보기로 점검하는 일러스트","caption":"모델 전환 전 프롬프트와 하네스의 성능, 보안, 비용을 점검하는 과정을 나타낸다.","description":null},"en":{"alt":"Illustration of AI cubes being inspected beside a warning barrier and checklist icons","caption":"The scene represents checking prompts, harnesses, performance, security, and cost before a model switch.","description":null},"ja":{"alt":"警告バリケードと確認項目のそばでAIキューブを虫眼鏡で点検するイラスト","caption":"モデル移行前にプロンプトやハーネスの性能、安全性、コストを確認する工程を表している。","description":null},"es":{"alt":"Ilustración de cubos de IA inspeccionados junto a una barrera de alerta e iconos de control","caption":"La escena representa la revisión de prompts, arneses, rendimiento, seguridad y costes antes de cambiar de modelo.","description":null},"id":{"alt":"Ilustrasi kubus AI yang diperiksa di dekat penghalang peringatan dan ikon daftar cek","caption":"Adegan ini menggambarkan pemeriksaan prompt, harness, kinerja, keamanan, dan biaya sebelum beralih model.","description":null},"pt":{"alt":"Ilustração de cubos de IA inspecionados junto a uma barreira de alerta e ícones de verificação","caption":"A cena representa a revisão de prompts, harnesses, desempenho, segurança e custos antes da troca de modelo.","description":null},"zh-hant":{"alt":"在警示柵欄與檢查圖示旁以放大鏡檢視 AI 方塊的插圖","caption":"此圖呈現模型切換前檢查提示詞、工具框架、效能、安全性與成本的流程。","description":null}}},{"id":325,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--5ddddd2dfbbbcedb1849fbdfe606aca94f9a98af/ai-b298a672.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"중앙 AI 모델에 보안, 문서, 사용자, 도구와 에이전트 차단 장치가 연결된 점검 구성도","caption":"모델 전환 전 프롬프트와 에이전트 하네스의 연결, 안전장치, 평가 항목을 점검하는 흐름을 나타낸다.","description":null},"en":{"alt":"AI model linked to security, documents, users, tools, agent controls, and evaluation indicators","caption":"The diagram contextualizes checks for prompts, agent harnesses, safeguards, and evaluations before a model switch.","description":null},"ja":{"alt":"中央のAIモデルにセキュリティ、文書、ユーザー、ツール、エージェント制御が接続された構成図","caption":"モデル移行前にプロンプトやエージェントハーネス、安全策、評価項目を確認する流れを示している。","description":null},"es":{"alt":"Modelo de IA conectado con seguridad, documentos, usuarios, herramientas, controles de agentes e indicadores","caption":"El diagrama representa la revisión de prompts, arneses de agentes, salvaguardas y evaluaciones antes de cambiar de modelo.","description":null},"id":{"alt":"Model AI terhubung ke keamanan, dokumen, pengguna, alat, kontrol agen, dan indikator evaluasi","caption":"Diagram ini menggambarkan pemeriksaan prompt, harness agen, pengaman, dan evaluasi sebelum pergantian model.","description":null},"pt":{"alt":"Modelo de IA ligado a segurança, documentos, usuários, ferramentas, controles de agentes e indicadores","caption":"O diagrama representa a verificação de prompts, harnesses de agentes, proteções e avaliações antes da troca de modelo.","description":null},"zh-hant":{"alt":"中央 AI 模型連接安全、文件、使用者、工具、代理控制與評估指標的架構圖","caption":"此圖呈現模型切換前對提示詞、代理框架、安全機制與評估項目的檢查流程。","description":null}}}],"published_at":"2026-07-28T11:42:11+09:00","updated_at":"2026-07-28T11:42:11+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/es/articles/claude-opus-5-verification-and-migration-guide"}