Guías, comparativas y novedades sobre herramientas de IA

Si un servidor MCP no conecta en Claude Code, revisa conjuntamente el estado, el método de conexión y los detalles de Issue. failed puede indicar un fallo de inicio stdio, un problema de comunicación HTTP o el rechazo de una cabecera fija de autenticación. El artículo explica Connection closed, las variables de entorno y las referencias no definidas, la configuración y aprobación del proyecto, el inicio de npx en Windows, los registros de depuración y las pruebas tras reconectar. También aclara por qué cero herramientas no implica necesariamente un error y por qué un inicio independiente no garantiza una conexión MCP correcta.

A veces Claude Code muestra "court" (o "call") seguido de etiquetas <invoke> en bruto y el comando nunca se ejecuta. No es tu entorno ni tu comando: es un fallo del lado del modelo al generar el token de control de la llamada a herramienta. El harness lo rechaza fail-closed, así que no hay riesgo de un comando equivocado; lo molesto es la cadena por autoenvenenamiento. Cubrimos el mecanismo, las causas, los errores comunes, las soluciones para usuarios y desarrolladores, cómo distinguirlo de errores parecidos y el estado oficial.

Un día tu cuenta de ChatGPT o Claude deja de funcionar de repente: en 2026 los reportes de suspensiones (baneos) y advertencias van en aumento, y lo que da miedo es que pueden banearte por incumplir las condiciones sin querer, incluso sin mala intención. Este artículo organiza lo que debes saber para no perder tu cuenta en OpenAI (ChatGPT, Codex) y Anthropic (Claude, Claude Code), con base en las políticas de uso publicadas y los reportes (no es una guía para esquivar la detección, sino para cumplir las normas). Cinco detonantes comunes a ambas: contenido prohibido / jailbreaks (generación ilegal o dañina, intentar romper los filtros de seguridad mediante prompts; las violaciones graves pueden ser un baneo permanente inmediato), automatización / scraping sin autorización (bots, scripts, accesos masivos engañosos como spam/phishing), compartir o revender cuentas/claves API, patrones de acceso sospechosos (cambios frecuentes de IP/país, uso intensivo de VPN, cambio de dispositivos leídos como inicios de sesión anómalos) y pago no coincidente/fraude (desfases geográficos, métodos de pago sospechosos). La mayor trampa de 2026: usar tokens OAuth de plan personal (Free/Pro/Max) de Claude en cualquier producto que no sea la app oficial, incluidos harnesses como el Agent SDK, es una violación de las ToS de consumidor que provocó una gran oleada de baneos; lo correcto es ejecutar apps/agentes vía la API (pago por uso) y tratar los planes personales como chat de la app oficial. Específicos de OpenAI: eludir restricciones de seguridad/acceso, automatización/scraping, reutilización indebida de claves API, usos ilegales. Específicos de Anthropic: mal uso de tokens OAuth de plan personal, acceso no oficial de terceros, cláusulas antidestilación/de modelos competidores, jailbreaks. Una lista de prevención de 7 puntos (lee la política, ajusta el plan al propósito, no metas tokens personales en herramientas de terceros, sin jailbreaks/contenido prohibido, no compartas ni revendas, pago que coincida con tu región y acceso estable, actúa de inmediato ante las advertencias). Las advertencias son una oportunidad de corregir y la mayoría puede continuar; las violaciones leves o accidentales pueden ser apelables, pero las graves son permanentes y difíciles de recuperar. El plan correcto, con el propósito correcto, de forma honesta. Confirma siempre las condiciones oficiales más recientes de cada empresa.

Volver a entrenar desde cero una IA gigantesca es demasiado caro, pero quieres ajustarla solo para ti; LoRA (Low-Rank Adaptation) cumple ese deseo congelando el modelo original y entrenando solo una pequeña pieza añadida (un adaptador), reduciendo los parámetros entrenables en torno a un 90%. LoRA abarata y acelera enormemente el fine-tuning, y es muy popular en la generación de imágenes como Stable Diffusion como un archivo pequeño que añade un personaje o un estilo. Este artículo lo explica con la analogía del parche. LoRA es el referente del ajuste fino eficiente en parámetros (PEFT): deja congelados los enormes pesos originales, inserta una pequeña matriz añadida en cada capa y entrena solo eso (W = W0 + BA, donde W0 está congelado y BA es la pequeña parte añadida). Se apoya en el descubrimiento de que adaptar una IA no requiere grandes cambios (basta un rango bajo). Ventajas: alrededor de un 90% menos de parámetros entrenables (según se informa, 10,000x menos a escala de GPT-3), menos memoria de GPU (unas 3x menos), entrenamiento más rápido y barato, sin latencia de inferencia una vez fusionado el adaptador, y menor riesgo de sobreajuste. Su mayor fortaleza son los adaptadores intercambiables: mantén una base común y cambia al instante pequeños archivos LoRA (de unos pocos MB) por caso de uso (soporte, tono de empresa, un personaje concreto). Mucha gente conoce LoRA por primera vez en la generación de imágenes, donde se comparten ampliamente LoRA de Stable Diffusion que aprendieron un personaje, estilo o sujeto (añadir un estilo, enseñar un personaje, ligero y fácil de compartir). QLoRA combina la cuantización, entrenando LoRA sobre una base de 4-bit para ~4x menos memoria que el LoRA estándar, lo que permite hacer fine-tuning de modelos enormes en una GPU de consumo (a veces CPU) con una pérdida de precisión mínima. Frente al fine-tuning completo (entrenar todos los pesos), LoRA difiere en los pesos entrenados, el coste, el resultado y el mejor uso; para la mayoría del trabajo, LoRA basta. Conserva la base, sazónala en pequeño. Las cifras se citan de materiales públicos, a modo orientativo.

Que un enorme modelo de 70B corra en un solo PC gaming en casa, en lugar de un rack de GPU de centro de datos, es posible gracias a la cuantización, que reduce la precisión numérica de los pesos de un modelo para encoger drásticamente su tamaño y memoria. Mientras la destilación traslada el conocimiento a otro modelo más pequeño, la cuantización hace más ligero el mismo modelo. Este artículo lo explica con una analogía de compresión de fotos. La cuantización reemplaza los pesos almacenados como decimales FP16/FP32 por enteros INT8 (8 bits) o INT4 (4 bits), recortando los bytes por peso (FP32=4, INT8=1, INT4=0,5); como comprimir una foto RAW a JPEG, sacrificas un poco de precisión a cambio de una gran reducción, y lo sorprendente es lo poco que renuncias. En memoria, 4-bit usa alrededor de un cuarto de FP16: un modelo de 70B baja de ~140GB a ~35GB, y uno de 8B a 4-bit ocupa ~4.5-5GB, que cabe en una GPU de gama media de 8GB de VRAM para uso local (la democratización de los LLM). En precisión, INT8 es casi sin pérdidas e INT4 se degrada por debajo del 4% en tareas generales de preguntas y respuestas o de sentido común, pero la pérdida es más notable en matemáticas, generación de código y razonamiento difícil (se manifiesta como un pequeño aumento de la perplejidad), así que elige el número de bits según la tarea. Métodos principales: GPTQ (pionero del 4-bit preciso), AWQ (protege el ~1% de los pesos más importantes, a menudo 1-2% más preciso y rápido), GGUF (formato llama.cpp/Ollama, Q2_K-Q8_0, híbrido CPU+GPU, para local) y QLoRA (base de 4-bit más LoRA para fine-tuning en GPU de consumo). Se diferencia de la destilación (trasladar a otro modelo pequeño) y del fine-tuning (añadir conocimiento de tarea), y las tres suelen combinarse (cuantizar un modelo destilado; hacer fine-tuning sobre una base cuantizada). Para empezar, ejecuta un modelo GGUF con Ollama en un comando, elige Q4/Q8 según la VRAM y evita INT4 para código o matemáticas exactas. La mayoría de los modelos principales ya vienen cuantizados, así que solo los descargas y usas. Conserva la inteligencia, suelta solo el peso. Las cifras se citan de materiales públicos, orientativas.

Una IA enorme y de alto rendimiento es inteligente pero pesada y cara; la destilación de modelos (knowledge distillation) resuelve esto transfiriendo el conocimiento de un gran modelo profesor a un pequeño modelo alumno, conservando más del 95% del rendimiento del profesor con una décima parte del tamaño y la velocidad. Este artículo lo explica con una analogía profesor-alumno. La clave son las soft labels: el entrenamiento normal solo enseña "la respuesta es gato" (hard label), mientras que la destilación transmite la distribución de probabilidad completa del profesor, como "90% gato, 8% perro, 2% zorro", cuyo grado de duda lleva información valiosa; un parámetro temperature suaviza las probabilidades para revelar relaciones sutiles (ejemplo real: GPT-4o mini destilado de GPT-4o). Ventajas: rápido y barato, ~10x más compacto conservando más del 95% del rendimiento, funciona en el edge, potente para la especialización. Dos enfoques: white-box (acceso completo a pesos y representaciones internas, transferencia más profunda; para modelos propios u OSS) y black-box (solo salidas/respuestas de API visibles; usar la API de otra empresa como profesor puede infringir los términos). Se diferencia de la cuantización (comprimir la precisión de los pesos del mismo modelo) y del fine-tuning (seguir entrenando un modelo existente para una tarea): la destilación mueve el conocimiento a un modelo pequeño aparte, y las tres son combinables. La realidad legal/ToS fue un gran tema en 2026: la técnica es legítima, pero OpenAI, Anthropic, Mistral y xAI incluyen cláusulas de destilación anticompetitiva que prohíben usar las salidas para crear modelos competidores, así que destilar un competidor desde una API restringida puede infringir los términos. La disputa OpenAI contra DeepSeek (OpenAI alegó que cuentas vinculadas a DeepSeek eludieron las restricciones para obtener salidas para destilación, mientras que los términos de DeepSeek, según los informes, permiten destilar sus salidas) muestra que la valoración depende de qué términos de API se aplican, y se informa que Claude Fable 5/Mythos 5 restringen las respuestas en trabajos marcados como destilación. Consejos: usa modelos propios u OSS con licencia como profesor, revisa las cláusulas anti-destilación antes de usar una API comercial y valora si el uso es "desarrollar un modelo competidor". La inteligencia, del modelo grande; la operación, del pequeño, pero a quién elijas como profesor cambia el resultado técnica y legalmente. Las cifras provienen de materiales públicos, son orientativas.

En "Cómo construir un sistema multiagente" dijimos que hay que instrumentar cada traspaso antes de añadir agentes; la tecnología que sostiene esa instrumentación en producción es la observabilidad de IA. Hace visible lo que los LLM y agentes hacen realmente en producción (qué modelo con qué prompt, qué herramientas y búsquedas, qué se devolvió y cuánto tiempo y dinero costó) para que puedas rastrear hasta la causa. La diferencia decisiva frente al monitoreo habitual: la IA puede devolver 200 OK en 50ms y aun así alucinar con seguridad, así que la mayoría de los fallos de IA son fallos de calidad (alucinación, recuperación débil, respuestas inseguras, tareas incompletas, mal uso de herramientas, regresiones tras cambiar el prompt), no de infraestructura. La observabilidad se apoya en tres pilares: trazas (una petición como un árbol de spans que muestra llamadas a LLM, herramientas, recuperación y cadenas de razonamiento; la estrella de la observación de IA), métricas (latencia, coste, tokens, tasa de errores, throughput) y logs (detalle por evento). El estándar del sector OpenTelemetry y sus convenciones GenAI capturan prompts, respuestas, uso de tokens y llamadas a herramientas/agentes en un esquema neutral que se puede enviar a Datadog/Grafana. La distinción más confundida es observabilidad frente a evaluación (evals): la observabilidad muestra qué pasó (fácil de medir, pero no dice si la respuesta es correcta), mientras que las evals miden si la respuesta es buena (precisión, fundamentación, seguridad) y requieren evaluación explícita. Como el coste y la latencia son fáciles de medir pero la calidad de la respuesta no, las herramientas de 2026 combinan la visualización de trazas con la puntuación de salidas y alertas de degradación. Las métricas se dividen en operativas (coste, latencia, tokens, tasa de errores) y de calidad (alucinación, fundamentación/faithfulness, lo más crítico en RAG, seguridad, cumplimiento de la tarea), con detección de alucinaciones mediante LLM-as-a-judge, similitud semántica y puntuaciones de groundedness. Herramientas principales: LangSmith (LangChain), Langfuse (autoalojable de código abierto), Arize Phoenix (depuración de RAG), MLflow (ciclo de vida), AgentOps (agentes) y OpenTelemetry (el estándar). Empieza capturando trazas (compatibles con OpenTelemetry), visualiza las métricas operativas y luego conecta las evals antes de pasar a producción. En los sistemas multiagente la observación es esencial, ya que los fallos se esconden en cadenas de varios pasos visibles solo en una traza de la sesión completa. Observar más evaluar es lo que hace que la IA sea de calidad de producción. Las figuras y los rasgos se citan de materiales públicos, a modo orientativo.

Tras comprender el concepto en "¿Qué es un sistema multi-agente?", esta es la continuación práctica. Usando el estándar de facto de 2026, el patrón supervisor, recorre una construcción de 5 pasos para principiantes. El principio clave: construye primero con un solo agente y añade más de forma mínima solo al topar con un límite (cerca del 80% de los casos se resuelven con uno; usar multi para trabajo simple de un único carril infla el coste 3-10x y, según investigación de Google, baja la precisión −39-70% en tareas secuenciales). Tres señales para pasar a multi: división por especialización, paralelismo y separación de decisiones. El patrón supervisor (el supervisor recibe la tarea global, la descompone, la delega en workers especializados y agrega los resultados) es donde han convergido los subagentes de Claude Code, LangGraph Supervisor y los handoffs de OpenAI Agents SDK, porque tiene el soporte de frameworks más amplio, un modo de fallo conocido (delegación excesiva, acotada por un tope de iteraciones) y es fácil de auditar. Los 5 pasos: 1) descompón la tarea con claridad desde el principio; 2) define workers con un rol + herramientas + formato de salida (3-5 máximo); 3) diseña el supervisor, enumerando explícitamente los nombres de workers a los que puede llamar (tope estricto) y dedicándole el máximo tiempo; 4) decide el handoff y el reparto de contexto, pasando solo lo necesario (el estándar es A2A); 5) instrumenta cada handoff antes de añadir agentes, pon topes a iteraciones/tokens/coste y configura evals y guardrails. El pseudocódigo independiente del framework muestra las definiciones de workers, un supervisor con tope estricto y un bucle de ejecución acotado por iteraciones. Errores comunes y soluciones: delegación excesiva (tope + limitar workers que se llaman), inflado de tokens (compartir solo lo necesario + caché), inestabilidad (mantener 3-5 + salida fija), caída de precisión en secuencial (volver a un solo agente) y punto de fallo desconocido (observabilidad). La lección compartida: los prompts, el diseño de herramientas y el arnés de evals deciden el éxito más que el framework. Construye pequeño, mide y amplía solo cuando compensa. Las cifras se citan de materiales públicos e investigación, dependientes del contexto.

Ahora que los agentes de IA son algo cotidiano, el siguiente reto es cómo lograr que colaboren entre sí. Si MCP conecta un agente con sus herramientas, A2A (Agent2Agent) conecta un agente con otro agente: un estándar abierto para que IAs creadas sobre distintos proveedores y frameworks se descubran, se comuniquen y cooperen mediante una convención común. Google lo publicó en abril de 2025, lo donó a la Linux Foundation ese junio y alcanzó la v1.0 en 2026. Esta guía para principiantes explica qué es A2A (con la analogía de la etiqueta de una alianza comercial), por qué hace falta (agentes especializados que se pasan el trabajo en relevo: un agente de planificación, uno de reserva de hotel y uno de pago), en qué se diferencia de MCP (MCP es vertical, agente ↔ herramientas; A2A es horizontal, agente ↔ agente; apilar ambos es la configuración estándar de dos capas), cómo funciona (una Agent Card —un JSON «tarjeta de visita» en /.well-known/agent-card.json— sirve para descubrir capacidades, luego una Task lleva la solicitud a través de estados como working, input-required y completed, y un Artifact devuelve el resultado, todo sobre HTTP, Server-Sent Events y JSON-RPC 2.0, con los agentes manteniendo ocultas sus interioridades) y su situación e implementación (a abril de 2026, más de 150 organizaciones en producción, más de 22.000 estrellas en GitHub, SDK en cinco lenguajes —Python, JavaScript, Java, Go, .NET— con Microsoft, Salesforce, SAP y ServiceNow participando). La regla mnemotécnica: conectar con herramientas = MCP, conectar con pares = A2A.

Construiste un sistema RAG pero la calidad de búsqueda es mediocre: justo ahí es donde ayuda el reranking. El reranking vuelve a puntuar por su relevancia respecto a la consulta los candidatos reunidos de forma aproximada por la búsqueda por embeddings (vectorial) y los reordena, conservando solo los mejores; este único paso puede cambiar drásticamente la calidad de las respuestas de un sistema RAG. Esta guía para principiantes cubre qué es el reranking (con la analogía de una primera criba y una entrevista final), por qué hace falta (la búsqueda por embeddings vectoriza la consulta y los documentos por separado, así que juzga la relevancia solo de forma tosca, y un mal orden reduce directamente la calidad de las respuestas; la investigación reporta en torno a un 40% de mejora de precisión en RAG al añadir reranking, y superponerlo a la hybrid search es el estándar de 2026), cómo funciona la recuperación en dos etapas («reunir amplio» con la rápida búsqueda por embeddings para el recall, luego «acotar con criterio» con el reranker para la precisión, y entregar los mejores al LLM), por qué un reranker es más preciso (un bi-encoder vectoriza la consulta y el documento por separado y es rápido pero aproximado; un cross-encoder los introduce juntos y produce una puntuación de relevancia de 0–1, preciso pero pesado, así que reúnes con el rápido bi-encoder y acotas con el preciso cross-encoder) y los modelos e implementación (tipo API como Cohere Rerank, Voyage y Jina; open-source como BGE reranker, mixedbread y FlashRank; y puntuación con LLM como RankLLM: basta con recuperar 50–100 y acotar a los 5 mejores). El principio: reunir amplio, acotar con criterio y afinar las cantidades con evaluaciones de IA.

Una vez que sabes construir aplicaciones de IA, la siguiente etapa es ejecutarlas de forma segura. Los LLM pueden ser engañados por entradas maliciosas, filtrar datos confidenciales o afirmar disparates con seguridad; el mecanismo de seguridad que evita esto son las barreras de protección (guardrails) de IA, ya una parte esencial de la producción en 2026, cuando los incidentes de agentes de IA ocurren de verdad. Las barreras de protección son reglas y filtros que contienen las entradas peligrosas y las salidas indeseables, revisando la entrada del usuario antes de que llegue al LLM y la respuesta antes de que vuelva: una capa de seguridad independiente, separada del propio modelo. Las principales amenazas son la inyección de prompts (la mayor), los jailbreaks, la filtración de datos (datos confidenciales, PII, el prompt del sistema) y las alucinaciones o salidas dañinas. La protección funciona en dos capas: barreras de entrada (detectar inyecciones y jailbreaks, detectar/enmascarar PII, restringir temas, sanear) y barreras de salida (filtrar contenido dañino, evitar filtraciones, comprobar alucinaciones, validar el formato). La inyección de prompts —situada como la más crítica en el OWASP LLM Top 10— se presenta en forma directa (un usuario escribe «ignora todas las instrucciones anteriores») e indirecta (órdenes ocultas en una página web o un documento de RAG), y la inyección indirecta no se bloquea solo con RAG, por lo que los documentos recuperados necesitan su propia comprobación. Esta guía para principiantes también cubre las herramientas (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard y las funciones de seguridad cloud de Azure, AWS y OpenAI) y los principios prácticos de defensa en profundidad, mínimo privilegio, aprobación humana y monitorización continua.

RAG, la búsqueda semántica y las recomendaciones dependen todas de un trabajador silencioso: el embedding (vector). Un embedding es el significado de un texto (o una imagen) convertido en una secuencia de números: un vector. La palabra "perro" se convierte en una lista de cientos a miles de números que actúan como "coordenadas del significado", de modo que las palabras con significado cercano quedan próximas ("perro" y "cachorro" están cerca; "perro" y "coche" están lejos), y la cercanía se cuantifica con medidas como la similitud del coseno. Ejemplo famoso: "rey − hombre + mujer ≈ reina". Gracias a esto, una máquina puede juzgar si el significado es cercano aunque los caracteres no coincidan. Esta guía para principiantes cubre qué es un embedding (un "mapa del significado"), por qué la cercanía mide el significado (dimensiones y similitud del coseno), para qué se usa (RAG, búsqueda semántica, clasificación y deduplicación, recomendaciones y multimodal), cómo elegir un modelo de embedding (tipo API como OpenAI text-embedding-3, Cohere, Gemini, Voyage; open source como BGE-M3, Nomic, Qwen3; además de Matryoshka, que puede reducir 3.072 dimensiones a 1.024 conservando alrededor del 95% de la calidad a aproximadamente un tercio del costo), y las bases de datos vectoriales (Pinecone, Weaviate, Qdrant, Chroma, pgvector) con un inicio en tres pasos (elegir un modelo, vectorizar y guardar documentos, vectorizar la pregunta y buscar). Los embeddings son la base para implementar RAG.