Guía de estudio CCAR-P

Cómo usar esta guía

Esta guía sigue exactamente la estructura de dominios y objetivos del Exam Guide oficial del Claude Certified Architect – Professional (CCAR-P), versión 1.0 de julio de 2026. Cada dominio del blueprint es una sección, y cada objetivo evaluable es un subtema que puedes abrir desde el menú lateral.

Cada objetivo responde siempre las mismas preguntas: qué es, por qué importa, cómo se aplica, un ejemplo del tipo de escenario que aparece en el examen, y los enlaces a la documentación oficial que respalda el concepto.

El orden recomendado de estudio es leer el dominio completo, resolver un simulacro y volver a los objetivos donde fallaste. Estudiar sin practicar te da una falsa sensación de dominio: el examen no evalúa si reconoces la definición, evalúa si eliges la arquitectura correcta cuando el escenario tiene tres opciones plausibles.

Referencia rápida del examen

Peso de cada dominio

Integration es el dominio de mayor peso y Developer Productivity el menor. Si tienes tiempo limitado, prioriza los dominios 3, 1 y 4: entre los tres concentran más de la mitad del examen.

Dominio 1: Solution Design & Architecture (17%)

Este dominio evalúa si el candidato puede pasar de “tenemos un problema de negocio” a “esta es la arquitectura que lo resuelve”, incluyendo cuándo usar agentes, cuándo no, y cómo justificar la decisión en términos de valor de negocio.

Translate business problems into Claude-based AI solutions

Qué es: el ejercicio de tomar un problema expresado en lenguaje de negocio (“perdemos demasiado tiempo triando tickets”, “los analistas tardan un día en resumir contratos”) y convertirlo en una especificación técnica: qué debe hacer el sistema, con qué datos, bajo qué restricciones, y cómo se medirá el éxito.

Por qué importa: es el primer punto de falla de cualquier proyecto de IA. Un arquitecto que empieza por el modelo (“usemos el más nuevo”) en vez de por el problema construye una solución elegante que no resuelve nada. El examen premia el orden: problema → restricciones → arquitectura → modelo, nunca al revés.

Cómo se aplica: discovery estructurado (ver Dominio 6) para extraer el problema real, los datos disponibles, las restricciones (latencia, costo, cumplimiento) y la definición de éxito, antes de dibujar ningún diagrama.

Ejemplo de examen: una reunión de arranque donde un ejecutivo anuncia “vamos a construir un sistema multiagente con el modelo más nuevo” antes de que exista un discovery. La respuesta correcta casi siempre es redirigir la conversación hacia el problema y las métricas, dejando la arquitectura como una decisión posterior y derivada.

Referencia: no hay una única página oficial para “traducir problemas de negocio”, es una disciplina de consultoría que el resto de la guía instrumenta con las herramientas de Anthropic. Ver el Dominio 6 para las técnicas concretas de discovery.

Design end-to-end architectures

Qué es: el patrón mental con el que se dibuja cualquier sistema de IA en producción: entra un input (pregunta del usuario, documento, evento), pasa por un procesamiento (prompt, retrieval, herramientas, orquestación), produce un output, y ese output junto con su desempeño real debe retroalimentar el sistema. Ese último paso, el feedback loop, es el que más se olvida.

Por qué importa: un sistema sin loop de feedback no puede mejorar, solo se puede reemplazar. El examen pone ítems donde un diagrama de arquitectura está casi completo salvo por la flecha de retorno desde monitoreo hacia evaluación, e identificar esa ausencia es un objetivo de examen explícito.

Ejemplo de examen: “un arquitecto revisa un diagrama con input, procesamiento, output y monitoreo, pero el monitoreo no conecta con nada”. La respuesta correcta es cerrar el loop hacia evaluación e iteración.

Referencia: Building Effective Agents, Anthropic

Select appropriate architectural patterns

Qué es: la decisión más fundamental de diseño. Anthropic define tres niveles crecientes de autonomía:

• Augmented LLM: un único modelo potenciado con retrieval, herramientas y memoria, sin orquestación multi-paso. Es el bloque de construcción básico.
• Workflow: el LLM y las herramientas se orquestan mediante código predefinido, es decir, la secuencia de pasos está fija de antemano (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer; ver Apéndice A).
• Agente: el LLM dirige dinámicamente su propio proceso y uso de herramientas, decidiendo en tiempo real cuántos pasos dar y en qué orden, usando feedback del entorno para corregirse.

Por qué importa: la guía de Anthropic es explícita: empieza con la solución más simple que cumpla los requisitos y aumenta la complejidad solo cuando las evaluaciones demuestren que mejora el resultado. Los agentes cambian latencia y costo por flexibilidad, y esa compra debe justificarse con evidencia, no con moda.

Ejemplo de examen: un caso donde una llamada única al modelo ya pasa las evaluaciones, pero el equipo propone 6 agentes porque “suena más avanzado”. La respuesta correcta es mantener el diseño simple.

Referencia: Building Effective Agents, Anthropic

Design multi-agent systems and orchestration strategies

Qué es: cuando un solo agente no basta, porque la tarea admite exploración en paralelo o porque se necesita separación de responsabilidades, se diseña un sistema orchestrator-workers: un agente líder descompone la tarea, delega a subagentes con contexto y herramientas propias, y sintetiza los resultados.

Por qué importa: el sistema de investigación multiagente de Anthropic mostró mejoras de desempeño sustanciales frente a un solo agente en tareas de exploración amplia (breadth-first), pero a un costo de tokens mucho mayor, de órdenes de magnitud. El patrón solo se justifica cuando la tarea se descompone en direcciones verdaderamente independientes y el valor de la tarea cubre ese costo. Riesgos propios de este patrón: el aislamiento de contexto entre workers, para que datos de una tarea no contaminen otra, y evitar que el orchestrator genere subagentes de más para preguntas simples.

Ejemplo de examen: due diligence sobre 300 documentos heterogéneos donde los subtemas emergen mientras se lee. Orchestrator-workers es la respuesta, porque la descomposición no puede fijarse de antemano.

Referencia: How we built our multi-agent research system, Anthropic

Apply decomposition techniques for complex problem solving

Qué es: cuando una tarea es demasiado grande o heterogénea para una sola llamada, se descompone en pasos más pequeños y verificables. La técnica base es prompt chaining: dividir la tarea en una secuencia fija de pasos, donde cada paso usa la salida del anterior, opcionalmente con una compuerta programática (validación por código) entre pasos.

Por qué importa: dividir el trabajo en subtareas con verificación intermedia sube la exactitud y baja la carga cognitiva por llamada, a cambio de latencia adicional. Es la técnica de menor complejidad dentro de los patrones agénticos y casi siempre es el punto de partida correcto antes de considerar orquestación multiagente.

Ejemplo de examen: “extraer partes, fechas y obligaciones, verificar conflictos y resumir” en un solo prompt falla. La solución es descomponer en subtareas encadenadas con una compuerta de verificación.

Referencia: Building Effective Agents, Anthropic

Align solutions to business value pillars

Qué es: un marco para clasificar y comunicar el valor de una solución de IA, útil para justificar inversión ante ejecutivos.

Por qué importa: confundir los pilares lleva a medir mal el éxito. Automatizar una cola existente (eficiencia y productividad, con línea base medible) es un tipo de apuesta; lanzar una capacidad nueva que la empresa no podía ofrecer (transformación, bajo incertidumbre, medida por valor estratégico) es otro tipo de apuesta completamente distinto. Cada uno exige métricas, apetito de riesgo y framing ejecutivo diferentes.

Ejemplo de examen: dos iniciativas compiten por presupuesto, automatizar una cola de documentos frente a lanzar una capacidad de venta nueva. Clasificarlas correctamente en el pilar correcto determina qué métricas de éxito son válidas para cada una.

Referencia: no existe una página única de Anthropic con este marco exacto, es una convención de valor empresarial estándar en la industria. Como respaldo de datos reales de adopción y valor de la IA en empresas, ver el Anthropic Economic Index.

Dominio 2: Claude Models, Prompting & Context Engineering (13%)

Este dominio evalúa decisiones de “cómo hablarle al modelo”: qué modelo usar, cómo estructurar el prompt, y cómo gestionar el contexto para que siga siendo eficaz y barato a medida que la conversación crece.

Select appropriate Claude models based on trade-offs

Qué es: elegir entre modelos rápidos y económicos (familia Haiku) y modelos más capaces (familia Sonnet y Opus) según la dificultad real de la tarea, no según preferencia.

Cómo se aplica: la guía oficial recomienda dos caminos de iteración:

1. Empezar barato: implementar con el modelo más rápido y económico, evaluar contra tu caso de uso, y escalar solo si hay una brecha de capacidad medida.
2. Empezar capaz: para tareas complejas, implementar con el modelo más capaz, optimizar el prompt, y luego considerar bajar de nivel o de “effort” una vez que las evaluaciones confirman que un modelo menor mantiene la calidad.

En ambos casos, el set de evaluaciones de tu propio caso de uso es el paso más importante. Un benchmark público no certifica que un modelo sirva para tu tarea específica.

Ejemplo de examen: un router que envía el 70% del tráfico a un modelo rápido y el 30% a un modelo capaz cumple simultáneamente metas de latencia, costo y calidad, mientras que usar el modelo más capaz para todo el tráfico incumple latencia y costo aunque tenga la calidad más alta.

Referencia: Choosing the right model, Claude Docs

Design system prompts, templates, and guardrails

Qué es: el system prompt es el lugar diseñado para fijar el rol, el tono, el alcance y las reglas duras de un asistente; todo lo demás (la tarea puntual, los datos) va en el turno de usuario. Un guardrail es cualquier instrucción o control que acota el comportamiento: qué no debe hacer, cuándo debe negarse, cuándo debe escalar a un humano.

Por qué importa: el rol en el system prompt es una de las técnicas de mayor impacto en prompt engineering, porque convierte a Claude de asistente genérico a experto de dominio y mejora exactitud, tono y foco simultáneamente. Además, el system prompt es el lugar natural para declarar la jerarquía de instrucciones, es decir, qué prevalece si el usuario contradice una regla del sistema.

Ejemplo de examen: un system prompt que ha acumulado meses de parches contiene instrucciones contradictorias (una dice “nunca reveles X”, otra dice “adapta el formato a lo que pida el usuario”). El diagnóstico correcto es auditar el prompt como un artefacto versionado y resolver el conflicto explícitamente, no añadir una tercera instrucción encima.

Referencia: Giving Claude a role with a system prompt, Claude Docs

Apply prompt engineering techniques

Qué es:

• Zero-shot: pedir la tarea directamente, con instrucciones claras y explícitas, sin ejemplos.
• Few-shot (multishot): mostrar de 3 a 5 ejemplos de entrada y salida representativos y diversos, incluyendo casos límite, envueltos en etiquetas <example> para que el modelo los distinga de la tarea real. Es una de las formas más confiables de fijar formato, tono y consistencia.
• Chain-of-thought (CoT): pedir razonamiento paso a paso antes de la respuesta final, útil en tareas de lógica, matemática o análisis de varios pasos. Se estructura con etiquetas como <thinking> y <answer> cuando el extended thinking nativo no está activo.

Por qué importa: cada técnica resuelve un problema distinto: zero-shot para tareas simples y bien especificadas, few-shot para fijar un formato o estilo exacto, CoT para tareas que se benefician de razonamiento explícito. Aplicar CoT a una tarea trivial solo añade costo y latencia sin ganancia de exactitud.

Ejemplo de examen: pares de ejemplos few-shot armados apresuradamente donde 11 de 12 tienen la misma frase distintiva en los positivos y ninguno en los negativos. El modelo aprende un atajo espurio (esa frase), no el concepto real. La corrección es un set balanceado y diverso, auditado contra regularidades accidentales.

Referencia: Use examples (multishot prompting), Claude Docs · Let Claude think (chain of thought), Claude Docs · Use XML tags, Claude Docs

Optimize context windows and manage token usage

Qué es: el contexto es un recurso finito y pagado. Todo lo que entra en la ventana (system prompt, historial, tool results, documentos) cuenta para el límite del modelo y para la factura. El context engineering es la disciplina de curar qué información vive en el contexto en cada momento, más allá de solo redactar bien el prompt.

Cómo se aplica:

• Retrieval just-in-time: en vez de precargar todo, mantener referencias ligeras (rutas de archivo, IDs) y cargar el contenido bajo demanda con herramientas.
• Compactación: resumir resultados de turnos anteriores conservando conclusiones y descartando verbosidad.
• Memoria externa: persistir hechos durables (decisiones, preferencias) fuera de la ventana, recuperando solo lo relevante por sesión.

Por qué importa: ventanas de contexto más grandes no garantizan mejor desempeño. El fenómeno de context rot describe cómo más tokens irrelevantes dificultan que el modelo mantenga el foco. Y aunque el límite técnico sea alto, el costo y la latencia escalan con lo que realmente se envía.

Ejemplo de examen: cargar un corpus de 5 GB completo en cada prompt “porque ahora las ventanas son grandes” es incorrecto incluso si técnicamente cupiera, porque el costo y la latencia por consulta escalan con el tamaño del contexto. Recuperar solo lo relevante sigue siendo el diseño correcto.

Referencia: Context windows, Claude Docs · Effective context engineering for AI agents, Anthropic

Implement prompt reuse strategies

Qué es: tres mecanismos para no reinventar contexto en cada llamada:

• Prompt caching: el prefijo estable de un prompt (system prompt, herramientas) se cachea. Las lecturas cuestan alrededor del 10% del precio de input normal y las escrituras alrededor del 125% con TTL de 5 minutos o del 200% con TTL de 1 hora. El orden correcto es contenido estable primero (tools, luego system, luego mensajes) y contenido variable al final, porque cualquier cambio dentro del prefijo invalida el cache completo.
• Prompts modulares: un system prompt parametrizado por audiencia o contexto, en vez de un prompt monolítico gigante, para poder mantener y versionar partes por separado.
• Skills: carpetas de instrucciones, scripts y recursos reutilizables que Claude carga automáticamente cuando son relevantes, con divulgación progresiva (solo se cargan al contexto cuando la tarea las necesita), ideales para estandarizar procedimientos en toda la organización.

Ejemplo de examen: un ingeniero hace un hotfix de una frase en el system prompt compartido en hora pico, y de inmediato suben el costo y la latencia en toda la flota. La causa es que el cambio invalidó el prefijo cacheado, y la práctica correcta es versionar y programar esos cambios deliberadamente.

Referencia: Prompt caching, Claude Docs · Agent Skills, Claude Docs

Dominio 3: Integration (19%)

Es el dominio de mayor peso del examen. Evalúa cómo conectar Claude con sistemas reales: qué protocolo usar, cómo asegurar el acceso, cómo diseñar retrieval y cómo mantener observabilidad a escala.

Evaluate tool/agent configuration for capability bloat

Qué es: el capability bloat ocurre cuando un agente tiene demasiadas herramientas, herramientas mal nombradas o solapadas, o resultados de herramientas demasiado verbosos. Todo eso degrada su capacidad de elegir la herramienta correcta y consume contexto innecesario.

Cómo se aplica: herramientas pocas, bien delimitadas y ortogonales, con nombres y descripciones claras (piensa en cómo le explicarías la herramienta a un colega nuevo); resultados paginados, truncados o filtrados en vez de volcados completos; y para catálogos grandes, de cientos de herramientas, usar divulgación progresiva, es decir, un índice ligero que carga la definición completa solo de las herramientas relevantes a la tarea actual.

Ejemplo de examen: un agente con 45 herramientas que selecciona la incorrecta con frecuencia. La solución es reducir al mínimo necesario por tarea y cargar el resto bajo demanda, no añadir un párrafo al prompt pidiendo “más cuidado”.

Referencia: Writing effective tools for AI agents, Anthropic · Tool use overview, Claude Docs

Analyze authentication and authorization requirements

Qué es: decidir qué credenciales usa un agente o conector para actuar en sistemas externos, y con qué alcance. El principio rector es mínimo privilegio: credenciales de vida corta, con rotación, con el alcance exacto que la tarea requiere y nada más.

Cómo se aplica:

• OAuth delegado cuando el agente actúa en nombre de un usuario final consciente, con consentimiento explícito y revocable. Es el modelo para conectores remotos MCP.
• Credenciales de servicio (machine-to-machine) para trabajo desatendido en nombre del sistema, no de una persona.
• Vinculación de audiencia: un token emitido para el servidor A no debe ser válido en el servidor B, lo cual evita el replay entre servicios.

Ejemplo de examen: un agente con una herramienta que solo necesita leer un sistema y escribir en una cola recibe credenciales de administrador de toda la organización “por simplicidad”. El gap de seguridad es la ausencia de mínimo privilegio, y la corrección es un scope estrecho, de vida corta, exclusivo para esas dos operaciones.

Referencia: MCP connector, Claude Docs · Model Context Protocol, especificación de autorización

Evaluate accuracy-latency trade-offs

Qué es: casi toda palanca de calidad tiene un costo en latencia, o al revés: extended thinking, reranking, más contexto recuperado, un modelo más grande. El trabajo del arquitecto es cuantificar ese trade-off y justificar la configuración elegida contra un requisito medible, no contra una preferencia.

Cómo se aplica: medir la curva de la palanca (por ejemplo, presupuesto de extended thinking frente a exactitud) y elegir el punto donde la ganancia marginal de calidad ya no justifica el costo marginal de latencia y tokens. Casi siempre esa curva tiene rendimientos decrecientes.

Ejemplo de examen: una curva de extended thinking donde la exactitud sube fuerte hasta 16k tokens, gana poco hasta 32k y se aplana después. La configuración defendible está alrededor de 16k a 32k, no el máximo disponible “por si acaso”.

Referencia: Extended thinking, Claude Docs · Reducing latency, Claude Docs

Analyze observability challenges and select monitoring strategies

Qué es: a diferencia del software determinista, un sistema con LLM necesita observabilidad que capture no solo si falló la petición, sino qué vio el modelo, qué recuperó, qué herramientas llamó y por qué respondió así. A escala, loguear todo con detalle completo es costoso, y la estrategia estándar es muestreo para el tráfico rutinario y trazas completas para errores y anomalías, con IDs de correlación que unen las llamadas al modelo, al retrieval y a las herramientas en una sola traza por solicitud.

Cómo se aplica: logging con reducción o tokenización de datos sensibles al momento de captura, control de acceso por rol sobre el almacén de trazas, retención definida, y métricas agregadas (tasa de cache-hit, p95 y p99 de latencia por etapa, tasa de refusals) con alertas sobre desviaciones.

Ejemplo de examen: una respuesta mala específica de un martes solo puede diagnosticarse con la traza completa de esa solicitud: qué se recuperó, con qué score, bajo qué versión de prompt. Un promedio semanal de satisfacción no sirve para ese diagnóstico puntual.

Referencia: Usage and Cost API, Claude Docs · Rate limits, Claude Platform Docs

Design a RAG pipeline with chunking and indexing strategies

Qué es: Retrieval-Augmented Generation (RAG) combina una base de conocimiento indexada con generación: el sistema recupera los fragmentos (chunks) más relevantes a la consulta y se los da al modelo como contexto antes de responder.

Cómo se aplica: la técnica de chunking debe reflejar la forma del dato: por función o clase en código, por sección en contratos, con solapamiento entre chunks para no cortar ideas en la frontera. Contextual Retrieval, la técnica de Anthropic, antepone a cada chunk un contexto breve generado por el modelo que describe su ubicación en el documento completo, lo cual reduce fallos de recuperación hasta un 49%, y hasta un 67% combinado con reranking, usando prompt caching para que el costo de generar ese contexto sea manejable.

Ejemplo de examen: una base de código indexada con chunks fijos de 500 tokens corta funciones a la mitad. La corrección es chunking consciente de la estructura, por función o clase, no chunks más pequeños del mismo tipo arbitrario.

Referencia: Introducing Contextual Retrieval, Anthropic

Apply retrieval strategies matched to data shape

Qué es: no toda consulta se resuelve igual. La búsqueda semántica (embeddings) captura parafraseo pero puede fallar con coincidencias exactas como SKUs o códigos de error; la búsqueda léxica (BM25) captura coincidencias exactas pero no parafraseo. La estrategia híbrida combina ambas, y el reranking se reserva para consultas ambiguas donde vale la pena el costo adicional.

Cómo se aplica: para catálogos con identificadores exactos, priorizar híbrido con peso léxico alto; para preguntas conversacionales, semántico con expansión de consulta si la consulta es muy corta; para preguntas multi-hop, retrieval iterativo agencial en vez de una sola pasada.

Ejemplo de examen: usuarios que buscan por SKU exacto reciben resultados pobres con búsqueda semántica pura. La solución es retrieval híbrido, léxico más semántico, no aumentar k indiscriminadamente.

Referencia: Introducing Contextual Retrieval, Anthropic

Evaluate connection protocols and select the integration mechanism

Qué es: tres mecanismos de integración con propósitos distintos.

MCP define tres primitivas: tools (acciones, controladas por el modelo), resources (datos de solo lectura, controlados por la aplicación) y prompts (plantillas reutilizables, controladas por el usuario, típicamente expuestas como comandos).

Ejemplo de examen: una organización necesita el mismo conector de CRM disponible igual en Claude Code, la app de escritorio y un agente propio. Construir tres integraciones a medida es incorrecto: un único servidor MCP reutilizado por los tres clientes es la respuesta.

Referencia: Model Context Protocol, especificación · MCP connector, Claude Platform Docs

Evaluate progressive discovery vs. monolithic context

Qué es: cuando un agente tiene acceso a un catálogo grande de herramientas o documentos existen dos estrategias: monolítica, cargar todo en el contexto desde el inicio, o divulgación progresiva, mantener un índice ligero y cargar el detalle completo solo de lo relevante a la tarea actual, bajo demanda.

Por qué importa: la estrategia monolítica es simple pero no escala. Con cientos de herramientas o documentos satura el contexto, sube el costo y degrada la precisión de selección. La divulgación progresiva es el patrón documentado para escalar, usado por ejemplo por las Skills y por el tool search de Claude.

Ejemplo de examen: una plataforma con más de 100 herramientas definidas por completo en cada prompt. La corrección es un índice ligero con búsqueda, cargando definiciones completas solo para las herramientas relevantes a la tarea en curso.

Referencia: Writing effective tools for AI agents, Anthropic · Agent Skills, Claude Docs

Dominio 4: Evaluation, Testing & Optimization (16%)

Este dominio evalúa la disciplina de medir: cómo se define el éxito, cómo se construyen datasets de evaluación, cómo se diagnostican fallas y cómo se optimiza costo y latencia sin sacrificar calidad.

Define evaluation metrics

Qué es: antes de construir nada, se acuerdan criterios de éxito específicos, medibles, alcanzables y relevantes para el caso de uso. “Buen desempeño” no es una métrica; “clasificación de sentimiento con 95% de exactitud en el set de prueba” sí lo es. La mayoría de aplicaciones necesita evaluación multidimensional: exactitud de tarea, latencia (p50, p95, p99), costo por resolución, seguridad (tasa de refusal correcta, resistencia a jailbreaks) y, cuando aplica, seguridad de la información.

Por qué importa: sin criterios acordados de antemano con los stakeholders de negocio, el éxito queda a discreción de quien mire el resultado y las decisiones de lanzamiento pierden su base objetiva.

Ejemplo de examen: definir las métricas de evaluación durante el discovery, junto con el stakeholder de negocio, en vez de al final del desarrollo o unilateralmente por ingeniería.

Referencia: Define success criteria and build evaluations, Claude Platform Docs

Design evaluation datasets and test frameworks

Qué es: un dataset de evaluación combina preguntas reales anonimizadas, para reflejar la distribución real de tráfico, con casos sintéticos de borde, etiquetados contra una rúbrica. La calificación combina tres métodos según qué tan objetiva sea la propiedad a medir.

Por qué importa: un juez LLM debe calibrarse contra etiquetas humanas, midiendo su acuerdo en vez de confiar ciegamente. Y un dataset pequeño iterado repetidamente termina sobreajustado, así que hay que mantener una porción held-out nunca usada para afinar prompts, reservada para la medición final.

Ejemplo de examen: dos anotadores humanos que discrepan en el 40% de los casos. Antes de usar esas etiquetas como verdad de referencia hay que refinar la guía de etiquetado y medir el acuerdo entre anotadores.

Referencia: Define success criteria and build evaluations, Claude Platform Docs

Conduct A/B testing and iterative improvements

Qué es: comparar una variante candidata contra la versión en producción sobre tráfico real, de forma controlada (asignación aleatoria, mismo período de tiempo, misma mezcla de tráfico) para aislar el efecto del cambio de otros factores como la estacionalidad.

Por qué importa: comparar variantes en períodos distintos, por ejemplo una semana de feriado frente a una semana normal, confunde el efecto del cambio con el efecto del calendario. Además, las diferencias pequeñas en muestras chicas suelen ser ruido estadístico y no señal real, así que antes de lanzar hay que verificar que la muestra sea suficiente para el tamaño de efecto que se busca detectar.

Ejemplo de examen: una prueba A/B donde la variante A corrió en semana de feriado y la B en semana normal, con B ganando. El resultado está confundido por estacionalidad y no es válido para decidir.

Referencia: no existe una única página oficial de Anthropic solo sobre metodología de A/B testing, es práctica estadística general. Ver la guía combinada de definición de criterios y evaluaciones, que la menciona como una de las técnicas de medición.

Diagnose system issues

Qué es: un conjunto de patrones de diagnóstico para cuando algo sale mal en producción.

• Alucinaciones: el modelo afirma algo no respaldado por el contexto. Mitigación: permitirle explícitamente decir “no lo sé”, pedir citas grounded en el texto fuente y verificar afirmaciones contra esas citas.
• Fallo de prompt: un cambio reciente en el prompt introdujo instrucciones contradictorias o mal calibradas, por ejemplo un pico de refusals justo después de editarlo.
• Model mismatch: el modelo elegido no es el adecuado para la dificultad real de la tarea, o el proveedor cambió el modelo detrás de un alias sin que el equipo lo fijara a una versión.

Ejemplo de examen: un sistema RAG empieza a dar respuestas confiadas pero incorrectas justo después de una actualización de documentos, sin cambios en latencia ni en la versión del modelo. El primer lugar a investigar es el paso de retrieval e indexación, con chunks obsoletos o mal indexados, no el modelo.

Referencia: Reduce hallucinations, Claude Platform Docs

Optimize token usage, latency, and cost-performance

Qué es: un conjunto de palancas concretas para bajar costo y latencia sin sacrificar la calidad ya validada.

• Prompt caching para prefijos estables reutilizados (ver Dominio 2).
• Batch API para trabajo diferible y no urgente: 50% de descuento en input y output, procesado de forma asíncrona.
• Routing por dificultad: modelos rápidos para lo simple, capaces para lo difícil.
• Streaming para mejorar la latencia percibida aunque la latencia total no cambie.
• max_tokens y stop sequences para evitar generación innecesaria.

Por qué importa: cada palanca debe verificarse contra el set de evaluación. Bajar el costo sin confirmar que la calidad se mantiene es optimizar a ciegas.

Ejemplo de examen: una carga de 40,000 resúmenes cada noche, sin restricción de tiempo real. La Batch API con el modelo más pequeño que pase las evaluaciones es la combinación correcta.

Referencia: Batch processing, Claude Docs · Reducing latency, Claude Platform Docs

Monitor system performance using logging and observability

Qué es: una vez en producción, el sistema necesita telemetría continua: uso y costo por equipo o feature (Usage & Cost API), tasa de acierto de cache, percentiles de latencia por etapa, y señales de calidad en producción como la tasa de escalamiento a humano, la tasa de pulgar abajo o la tasa de reformulación inmediata de la misma pregunta, que funcionan como proxies tempranas mientras se espera una revisión humana más lenta.

Ejemplo de examen: finanzas pide desglosar el gasto en modelo por feature y equipo. Esto requiere accounting de tokens por solicitud etiquetado con metadata de feature y equipo, respaldado por API keys o workspaces separados por equipo, no un reparto parejo de la factura total.

Referencia: Usage and Cost API, Claude Docs · Workspaces, Claude Platform Docs

Dominio 5: Governance, Safety & Risk Management (14%)

Este dominio evalúa controles: cómo se limita el riesgo de un sistema con LLM, cómo se involucra a humanos y cómo se cumplen regulaciones como GDPR, HIPAA y FedRAMP.

Implement guardrails and safety controls

Qué es: controles en capas a lo largo de toda la cadena: screening de input para detectar contenido malicioso antes de que llegue al modelo, a menudo con un modelo pequeño y rápido como clasificador; system prompt endurecido, que trata el contenido de terceros como datos y nunca como instrucciones; y validación de output antes de mostrarlo o de actuar sobre él. Ninguna capa aislada es suficiente: la defensa efectiva es en profundidad.

Por qué importa: la inyección de prompt indirecta, es decir, instrucciones maliciosas escondidas en un documento o correo que el modelo procesa, es uno de los riesgos mejor documentados en aplicaciones LLM y encabeza el OWASP Top 10 para LLM. No se resuelve con un único filtro: requiere que el contenido recuperado se trate siempre como dato, con confirmación humana antes de acciones sensibles.

Ejemplo de examen: un asistente que resume correos recibe uno con texto oculto que le instruye reenviar información de nómina. El diseño correcto trata el contenido leído como dato y nunca como autoridad, exige confirmación explícita para acciones sensibles y no depende de que el modelo note el truco.

Referencia: Mitigate jailbreaks and prompt injections, Claude Platform Docs · OWASP Top 10 for LLM Applications

Identify risks, limitations, and failure modes

Qué es: un inventario consciente de cómo puede fallar un sistema con LLM: alucinación, sesgo heredado de los datos de entrenamiento, fuga de información sensible vía prompt o logs, uso indebido de herramientas con acciones no autorizadas, y sobreconfianza del usuario en respuestas incorrectas (over-reliance).

Cómo se aplica: clasificar acciones por reversibilidad e impacto para decidir niveles de autonomía, automatizando lo reversible y de bajo impacto y exigiendo aprobación humana para lo irreversible o de alto impacto, y mantener un plan de respuesta a incidentes específico para IA con clasificación de severidad, kill-switch, comunicación y postmortem.

Ejemplo de examen: decidir qué acciones de un agente pueden ejecutarse de forma autónoma y cuáles requieren aprobación humana. El eje decisivo es la reversibilidad y el radio de impacto, no la antigüedad de la herramienta ni el orden alfabético.

Referencia: NIST AI Risk Management Framework · OWASP Top 10 for LLM Applications

Apply human-in-the-loop validation strategies

Qué es: definir dónde y cómo interviene un humano en el proceso: aprobación previa a la acción para lo irreversible o de alto valor, revisión muestreada posterior para riesgo medio, o monitoreo automático continuo para riesgo bajo. Un patrón común para acciones consecuentes es proponer, aprobar, ejecutar: el agente prepara el cambio exacto y su justificación, un humano aprueba, y solo entonces se aplica.

Por qué importa: calibrar mal el nivel de supervisión, revisando todo (que no escala) o no revisando nada (que expone a errores costosos), es uno de los errores de diseño más comunes en sistemas agénticos con acciones reales.

Ejemplo de examen: un agente de refunds que hoy puede emitir reembolsos de cualquier monto de forma autónoma. El primer control a añadir es una compuerta de aprobación humana por encima de un umbral de valor definido, con la herramienta de refund acotada a operaciones reversibles.

Referencia: Building Effective Agents, Anthropic, sección de checkpoints y supervisión humana

Ensure compliance with regulations

Qué es: tres marcos regulatorios que el examen espera que reconozcas a nivel de arquitectura, no de asesoría legal.

Ejemplo de examen: un cliente de gobierno exige cumplimiento FedRAMP. La consideración decisiva es operar dentro de un entorno con autorización FedRAMP vigente, verificando que el nivel y el alcance de la autorización cubran los servicios usados, no la versión del modelo ni el prompt.

Referencia: HIPAA Security Rule, HHS.gov · GDPR Art. 17 · GDPR Art. 35 · FedRAMP.gov

Address ethical AI considerations

Qué es: monitoreo continuo, no solo previo al lanzamiento, de tasas de error y resultado por segmento relevante, con alertas ante divergencias significativas; disclosure de cuándo el contenido es generado por IA; y explicabilidad suficiente para que una decisión relevante pueda reconstruirse, sabiendo qué versión de prompt, qué fuentes y qué llamadas a herramientas la produjeron.

Por qué importa: la equidad no es una propiedad que se certifica una vez. Se degrada con el tiempo a medida que cambian los datos de entrada y el comportamiento del sistema, por lo que requiere monitoreo continuo con el mismo rigor que cualquier otra métrica de producción.

Ejemplo de examen: un asistente de préstamos que fue evaluado por equidad solo antes del lanzamiento. La gobernanza correcta es monitoreo continuo de tasas de error por segmento, con alertas y remediación, no una sola prueba inicial.

Referencia: NIST AI Risk Management Framework · Anthropic Transparency Hub

Dominio 6: Stakeholder Communication & Lifecycle Management (14%)

Este dominio evalúa habilidades de arquitecto consultor: cómo se descubre el problema real, cómo se comunican decisiones técnicas a audiencias no técnicas y cómo se gestiona el sistema durante todo su ciclo de vida.

Conduct structured discovery and requirement gathering

Qué es: la fase que produce, antes de cualquier decisión técnica, el problema de negocio en una frase, métricas de éxito medibles, restricciones (latencia, costo, cumplimiento, residencia de datos) y un inventario de los datos y sistemas disponibles.

Por qué importa: un discovery incompleto se descubre tarde y caro, típicamente cuando legal o seguridad bloquean el proyecto en la revisión de lanzamiento porque no fueron consultados desde el principio.

Ejemplo de examen: legal ve el asistente por primera vez en la revisión de lanzamiento y lo bloquea por manejo de datos. La práctica que previene esto es involucrar a los stakeholders de cumplimiento y legal desde el discovery, no al final.

Referencia: no existe una página única de Anthropic sobre metodología de discovery, es práctica de consultoría. Las restricciones técnicas que el discovery debe capturar están descritas a lo largo de los Dominios 3 y 5 de esta guía.

Communicate architectural decisions and trade-offs

Qué es: presentar una decisión de arquitectura a un comité ejecutivo liderando con resultados de negocio, costo, riesgo y cronograma, dejando el detalle técnico en un apéndice, y documentar el razonamiento detrás de decisiones significativas con un registro de decisiones de arquitectura (ADR) para que el equipo futuro entienda por qué se decidió así cuando las condiciones cambien.

Ejemplo de examen: presentar tres arquitecturas candidatas a un comité de dirección. La comparación debe hacerse en una matriz de trade-offs (calidad, costo, latencia, riesgo, tiempo de entrega) con una recomendación razonada, no mostrando el código o los prompts de cada opción.

Referencia: no existe una única página oficial de Anthropic sobre este tema, es práctica general de comunicación técnica y de Architecture Decision Records.

Manage stakeholder feedback loops and expectation alignment

Qué es: un ritmo recurrente, por ejemplo una revisión periódica con el dueño de producto examinando transcripciones y métricas reales, que convierte evidencia de producción en un backlog priorizado de mejoras. Y para compromisos contractuales, un SLA defendible: objetivos de percentil de latencia y disponibilidad que la arquitectura demostrablemente cumple, con modos de degradación definidos y exclusiones razonables como caídas de terceros o ventanas de mantenimiento.

Ejemplo de examen: un cliente empresarial exige un SLA sin ninguna exclusión. La posición defendible es comprometerse a objetivos medibles que la arquitectura sí controla, con exclusiones estándar para lo que está genuinamente fuera de su control, porque garantías sin exclusión prometen un control que el proveedor no tiene.

Referencia: no existe una única página oficial de Anthropic sobre este tema, es práctica de gestión de producto y relación con clientes.

Document architectures and provide implementation guidance

Qué es: documentación en capas por audiencia: resumen de valor y riesgo para ejecutivos, diagramas de componentes y flujo de datos para ingeniería, runbooks y dashboards para operaciones, manteniendo las tres consistentes entre sí, más un paquete de handoff que incluya el registro de versiones de prompts y el proceso de cambio autorizado.

Ejemplo de examen: la misma arquitectura debe explicarse a la junta directiva, al gremio de ingeniería y a operaciones. La estrategia correcta son tres vistas por audiencia mantenidas consistentes entre sí, no un único artefacto para todos ni documentación solo para ingeniería.

Referencia: no existe una única página de Anthropic sobre este tema, es práctica general de documentación de arquitectura de software aplicada a sistemas con IA.

Support lifecycle phases

Qué es: el ciclo de vida completo de una solución de IA en producción, representado en el diagrama de esta sección. Discovery define el problema y las restricciones; design produce la arquitectura y sus evaluaciones; handoff entrega el sistema al equipo que lo operará, con documentación y KPIs ya definidos; monitoring observa el sistema en producción; e iteration convierte esa evidencia en cambios, reabriendo el ciclo hacia design.

Por qué importa: las fases no son lineales de una sola pasada. Es un ciclo, y saltarse monitoring o iteration, evaluando una sola vez antes del lanzamiento, hace que la calidad del sistema quede congelada en el momento del lanzamiento mientras el mundo real sigue cambiando.

Ejemplo de examen: definir a nivel de discovery cuándo el sistema debería eventualmente retirarse, con criterios de sunset como el estancamiento sostenido de KPIs o un costo insostenible, es parte madura de gestionar el ciclo de vida completo y no un tema tabú a evitar.

Referencia: Building Effective Agents, Anthropic, el loop de feedback como parte estructural de la arquitectura

Dominio 7: Developer Productivity & Operational Enablement (7%)

El dominio de menor peso, centrado en cómo un arquitecto habilita a los equipos de desarrollo para trabajar de forma efectiva y segura con herramientas asistidas por IA, principalmente Claude Code.

Configure Claude tools and environments for teams

Qué es: Claude Code es una herramienta de código agéntica que lee el repositorio, edita archivos, ejecuta comandos y se integra con las herramientas de desarrollo, disponible en terminal, IDE, app de escritorio y navegador. La configuración de equipo típica incluye un CLAUDE.md versionado en el repositorio con instrucciones persistentes de proyecto, servidores MCP para sistemas internos, y una postura de permisos que define qué acciones requieren aprobación explícita, apropiada al nivel de riesgo del repositorio.

Ejemplo de examen: los desarrolladores nuevos tardan días en configurar un entorno productivo por repositorio. La práctica correcta es versionar CLAUDE.md, los comandos y la configuración de herramientas dentro del repositorio, para que el entorno sea idéntico y reproducible desde el primer clone.

Referencia: Claude Code, Overview · Cómo Claude recuerda tu proyecto (CLAUDE.md)

Improve developer workflows using AI-assisted tooling

Qué es: patrones que aumentan la productividad real y no solo la percibida: comandos personalizados para flujos que se repiten, hooks que ejecutan lint y tests automáticamente tras cada edición (control determinista, que no depende de que el modelo se acuerde), y servidores MCP que conectan Claude Code con sistemas internos como tickets o documentación, como fuentes de contexto gobernadas.

Ejemplo de examen: un equipo repite cada semana el mismo flujo de notas de versión en Claude Code, reexplicándolo cada vez. Un comando personalizado versionado en el repositorio, que codifica el flujo como una invocación reutilizable, elimina la repetición.

Referencia: Claude Code: Best practices for agentic coding, Anthropic · Hooks, Claude Code Docs · Slash commands, Claude Code Docs

Support debugging and operational issue resolution

Qué es: el uso apropiado de Claude durante incidentes y automatización operativa. En modo headless, no interactivo, dentro de CI, con permisos acotados y salida estructurada, para tareas como la revisión automática de pull requests. Y como asistente de diagnóstico durante un incidente, analizando logs y contexto para proponer hipótesis rankeadas con pasos de verificación, manteniendo siempre al humano con la autoridad de cambio.

Ejemplo de examen: un ingeniero quiere ayuda de IA durante un incidente en producción sin ceder el control. El flujo correcto es dar logs y contexto, pedir hipótesis rankeadas con verificación para cada una, y que el ingeniero valide antes de aplicar cualquier cambio. Nunca dejar que el agente aplique el cambio directamente a producción.

Referencia: Headless mode, Claude Code Docs · GitHub Actions, Claude Code Docs

Apéndice A: Los 5 patrones de Building Effective Agents

Anthropic documenta 5 patrones de workflow, con código predefinido y sin autonomía del agente, que suelen resolver la mayoría de casos antes de necesitar un agente autónomo completo. Prompt chaining y orchestrator-workers ya se diagramaron en el Dominio 1; aquí se consolidan los 5 en una tabla y se diagraman los tres restantes.

Regla general de decisión: empieza por la solución más simple, una llamada única o un augmented LLM, y sube de nivel en esta lista solo cuando la evaluación demuestre que la complejidad adicional mejora el resultado lo suficiente para justificar el costo y la latencia extra que añade.

Referencia: Building Effective Agents, Anthropic

Apéndice B: Cómo razonar las preguntas de muestra

El Exam Guide oficial incluye 3 preguntas de muestra en su Sección 8 que ilustran el estilo y el nivel cognitivo del examen real. Aquí no se reproducen: se analiza por qué cada una tiene esa respuesta, como entrenamiento de razonamiento de examen.

Muestra 1 (Dominio 3, mínimo privilegio): la clave del ítem es distinguir entre controles de eliminación de privilegio, es decir, remover la herramienta que no se necesita, y controles detectivos o compensatorios como logging y confirmación. El examen premia la opción que elimina la superficie de ataque, no la que la vigila ni la que cambia un factor sin relación, como el tamaño del modelo.

Muestra 2 (Dominio 2, prompt caching): la clave es reconocer que el problema real, latencia y costo por un prefijo repetido en cada llamada, tiene una solución arquitectónica específica: ordenar el contenido estable primero y habilitar prompt caching. Y descartar opciones que suenan relacionadas pero no atacan la causa, como truncar contenido necesario, bajar de modelo a ciegas o reubicar el contenido sin generar un prefijo cacheable.

Muestra 3 (Dominio 4, diagnóstico RAG): la clave es el diagnóstico por eliminación. Si la latencia y la versión del modelo no cambiaron, pero la calidad cayó justo después de un refresh de documentos, la causa más probable está en la etapa que sí cambió, retrieval o indexación, no en el modelo ni en un parámetro de muestreo sin relación con el evento.

Patrón general para todo el examen: casi todos los ítems siguen esta estructura. Un escenario con una causa específica insinuada por los detalles (qué cambió, qué se mantuvo constante), entre 4 y 5 opciones donde 2 o 3 son plausibles en abstracto pero no atacan la causa real, y una sola opción que resuelve exactamente lo que el escenario describe. Leer qué no cambió en el escenario es tan informativo como leer qué sí cambió.

Apéndice C: Estrategia de examen y glosario

Estrategia para el día del examen

• 120 minutos para 63 ítems, es decir 1 minuto y 54 segundos por ítem en promedio. Los ítems de “elige dos” suelen tomar más tiempo, así que no te quedes atascado: márcalo mentalmente y continúa.
• Sin penalización por adivinar: responde todo, incluso los ítems donde no estés seguro.
• En ítems de “elige dos”, ambas respuestas deben ser correctas para obtener el punto. Descarta primero las opciones que resuelven un problema distinto al planteado en el escenario.
• Busca en el escenario qué cambió y qué se mantuvo constante justo antes del síntoma descrito. Casi siempre ahí está la causa real.
• Cuando dos opciones parezcan igual de razonables, prefiere la que ataca la causa raíz sobre la que trata un síntoma. Por ejemplo, “revisar el prompt que se editó” antes que “cambiar de modelo”.
• Desconfía de las opciones extremas (“nunca”, “siempre”, “eliminar por completo”, “ningún control”) salvo que el escenario sea exactamente ese caso límite.
• Para ítems de gobernanza y cumplimiento, la opción correcta casi siempre combina prevención, supervisión y registro, no solo una de las tres.

Glosario mínimo

Guía preparada a partir del Exam Guide oficial CCAR-P v1.0 (julio de 2026) y de documentación oficial de Anthropic verificada en julio de 2026. Los enlaces apuntan a la página específica de cada tema. Donde no existe una fuente única autoritativa, por ejemplo en práctica de consultoría o comunicación ejecutiva, se indica explícitamente en vez de forzar una referencia poco precisa.