# Usar IA con una placa, sin respuestas inventadas. > Una guía práctica: por qué un chatbot general inventa componentes, qué significa de verdad anclar la IA en una placa, y por qué cada tipo de dato (esquemático, boardview, foto, documento, web) necesita su propio tratamiento para servir en la mesa. Source: https://wrenchboard.cloud/es/usar-ia-para-reparar-placas Un chatbot general responde igual haya leído tu placa o no. Este es el método que cambia eso: cada afirmación sale de una consulta, cada tipo de dato se trata según lo que de verdad sabe, y la respuesta tiene la forma de la evidencia en lugar de la de un párrafo. ## Por qué un chatbot general *falla con una placa* Pregúntale a cualquier modelo general dónde está el fusible de entrada en una tarjeta madre de laptop que nunca ha visto. Te va a responder. Te va a dar un designador de referencia, una ubicación y un tono de voz que suena exactamente igual al que usa cuando tiene razón. Esto no es un defecto que se arregle con un mejor prompt. Un modelo de lenguaje produce la continuación más probable, y en una placa lo probable sale barato: los refdes se parecen, las líneas de voltaje se nombran igual entre fabricantes, y `C29` existe en casi cualquier placa que se haya hecho. El modelo no tiene ningún mecanismo para decir "no lo encontré", porque nada en él buscó nunca. En la mesa, el costo no es una respuesta vergonzosa. Es un componente desoldado que estaba bien. ## La regla que lo cambia todo: *solo puede hablar a partir de una consulta* La solución es de arquitectura, no de conversación. Cada componente que nombra el agente tiene que salir de una llamada a una herramienta sobre tu placa realmente analizada o sobre el grafo construido a partir de tu esquemático real. No de su entrenamiento, no de su memoria de la conversación. Dos capas hacen que eso se cumpla en WrenchBoard. Las herramientas mismas nunca inventan: pídeles un refdes desconocido y devuelven "no encontrado" con las coincidencias más cercanas, lo que obliga al agente a elegir entre nombres reales o a preguntarte. Y a la salida, todo lo que tenga forma de refdes se comprueba contra la placa analizada, así que un nombre que la placa no contiene te llega marcado como en verificación en lugar de presentarse como un hecho. Esa es toda la diferencia entre un asistente que ayuda y uno que se equivoca con seguridad, y vale la pena comprobarla en cualquier herramienta que evalúes: **pregúntale por un componente que no existe en tu placa.** Una herramienta anclada dice que no lo encuentra. Un chatbot te lo describe. ## Cada tipo de dato *responde una pregunta distinta* Esta es la parte en la que casi todos se equivocan, porque es tentador tratar cada archivo como "contexto para pegar". Cada formato lleva una verdad distinta, y pierde su valor en el momento en que se aplana en texto. - **El boardview** sabe de geometría. Dónde está el pad, qué pads comparten una net, qué hay del otro lado de la placa. No sabe para qué sirve nada de eso. - **El esquemático** sabe de topología. Qué alimenta a qué, qué línea cae cuando cae esta, qué se supone que es un pin. No sabe dónde poner tu punta. - **La foto que acabas de tomar** sabe del presente. La sulfatación, el chip con reballing, el puente que dejó el técnico anterior. Nada de eso está en ningún documento. - **La hoja de datos o el manual de servicio** saben de intención. Para qué se diseñó el componente, qué esperaba medir la fábrica. - **La web** sabe de lo colectivo. Que este modelo tiene un regulador que falla con frecuencia, que un lote salió con pads malos. Útil, no verificable, y hay que tratarlo como una pista y no como un hecho. Un agente que maneja los cinco como un solo bloque indiferenciado de texto te da una respuesta promedio. Uno que los mantiene separados puede cruzarlos: el esquemático dice que esta net debería estar a 3.3 V, el boardview dice que el pad más cercano está aquí, tu foto dice que ese pad está sulfatado, y de repente la medición que hay que tomar es obvia. ## Mirar es una herramienta, *no un párrafo* Una página de esquemático no se puede leer como texto. La información está en la disposición: qué línea sale de qué pin, qué etiqueta está sobre qué cable. Así que el agente no recibe una transcripción de la página, la puede **mirar** y encuadrar lo que mira, acercándose a una zona de una hoja igual que tú pasarías una lupa sobre un esquemático impreso. Lo mismo con tus fotos: encuadra la zona que necesita en lugar de forzar la vista sobre toda la placa de una vez. Por eso también la respuesta nunca debería ser "por ahí cerca del CPU". Debería ser una hoja, una zona y un componente. ## Cómo trabajar con ella, *en la práctica* **Dale el síntoma, no tu diagnóstico.** "Muerta, sin LED, cargador de 20 V conectado" vale más que "creo que el PMIC está muerto". Lo segundo reduce la búsqueda a tu hipótesis, que es justamente lo que quieres que se compruebe. **Mide lo que te pide, en el orden en que te lo pide.** El orden no es arbitrario: cada medición se elige para eliminar la rama más grande del árbol de fallas. Si las tomas fuera de orden, pierdes esa eliminación. **Reporta los fallos con la misma precisión que los aciertos.** "0 V" y "OL" son hechos distintos, y un paso de protocolo que falla le dice más al agente que uno que pasa. **Contradícelo.** A un agente anclado se le puede contradecir con una medición, y debería cambiar su clasificación cuando lo haces. Si el tuyo defiende su primera hipótesis contra tu multímetro, no estás usando una herramienta de diagnóstico, estás discutiendo con un autocompletado. ## Una lectura no es una respuesta, *es una fila* **La placa y el chat son el mismo cuarto.** Señala cualquier pin en el inspector y viaja con tu siguiente mensaje como una etiqueta, `F2 pin 1 (BAT1FUSED)`. Nunca escribes un refdes, el agente nunca tiene que adivinar a qué F2 te refieres, y cuando una de sus vistas ofrece una medición, el botón le devuelve el punto directamente. Esa es la parte que la gente espera que sea un truco de demo: las dos mitades están conectadas, así que una lectura tomada en la placa llega al contexto del agente sin pasar por tu teclado. Di "F2 marca OL" y un agente anclado no se limita a darte la razón. Llama a una herramienta que anota la lectura: qué se midió, en qué componente o pin, qué se esperaba, y un modo de falla que el motor clasifica por su cuenta: abierto, corto, muerto o degradado. La lectura se vuelve una fila en la bitácora de esta reparación, ligada a aquello sobre lo que se tomó. De ahí salen tres cosas, y juntas son todo el argumento a favor de una herramienta frente a una ventana de chat. **La siguiente clasificación la lee.** Pide hipótesis otra vez y las observaciones entran con ellas. El orden cambia porque cambió un hecho, no porque insististe. Para eso sirve una clasificación. **La siguiente sesión también la lee.** La bitácora se puede consultar, así que una placa que viste hace seis meses no empieza de cero, y tampoco la siguiente placa con el mismo síntoma en el mismo modelo. **Y nada se vuelve a escribir.** La medición que tomaste en la mesa es la medición que imprime el reporte, la que el protocolo marca como hecha y la que guarda la base de conocimiento. La ingresaste una sola vez. Esta es la parte que no se ve en una demo, y es la que decide si un agente sirve en una mesa de trabajo: las herramientas y los datos son el mismo objeto. Un grafo del esquemático que responde por net, una base de reglas que responde por síntoma, una bitácora que se puede escribir y releer, un boardview que se puede señalar y sobre el que se puede medir. Un modelo sin nada de eso tiene que adivinar. Un modelo conectado a todo eso puede medir, y se le puede demostrar que se equivoca. ## Dónde queda *el modelo* Fíjate en lo que el modelo no está haciendo en todo esto. No está recordando tu placa, no la está reconociendo en una foto, no está recordando una reparación de su entrenamiento. Está eligiendo qué herramienta llamar después, leyendo lo que regresa y decidiendo qué vale la pena medir. El conocimiento vive en el grafo, las reglas y la bitácora. El modelo pone el razonamiento. Por eso también una respuesta no debería verse como la transcripción de un chat. Un valor esperado frente a uno medido, una clasificación con sus números, un protocolo con sus pasos: la forma de la evidencia, no la forma de una conversación. ## Preguntas frecuentes ### ¿Puedo simplemente pegar mi esquemático en ChatGPT? Puedes, y te va a responder. El problema es que responde igual haya leído tu placa o no. Un modelo general no tiene forma de decirte que no encontró C29, así que produce un C29 creíble. En una placa, una respuesta creíble te cuesta un componente dañado y una tarde. Lo que cambia el resultado no es un mejor modelo, es un modelo que solo puede hablar a partir de una consulta. ### ¿Qué significa aquí 'anclado', en la práctica? Que cada designador de referencia que te muestra el agente salió de una llamada a una herramienta sobre tu placa analizada o sobre el grafo del esquemático, nunca de su memoria. Cuando un refdes no se puede verificar, se marca como en verificación en lugar de afirmarse, y la verificación se hace sobre la frase completa antes de confirmarla. Esa garantía está en el motor, no en el prompt. ### ¿Por qué importa tanto el tipo de archivo? Porque cada uno responde una pregunta distinta. Un boardview sabe dónde está un pad, no qué hace. Un esquemático sabe qué está conectado con qué, no dónde poner la punta. Una foto sabe cómo se ve tu placa hoy, incluida la sulfatación que nadie documentó. Una hoja de datos sabe qué se supone que hace un componente. Un agente que trata los cuatro como 'texto que leer' tira justo lo que hacía útil a cada uno. ### ¿Debo usar el nivel de razonamiento más profundo siempre? No, y no es por ahorrar dinero. Un nivel profundo ante una pregunta que necesita una sola consulta produce una respuesta larga construida sobre un solo dato, que suena más segura de lo que es. La profundidad vale la pena cuando la placa se resiste: un síntoma con varias causas posibles, una línea que cae con carga, una reparación que ya falló una vez. ### ¿La IA reemplaza mis habilidades? No. Reemplaza las horas que pasas buscando en páginas de PDF la única net que importa. Tú sigues midiendo, sigues leyendo el multímetro, sigues decidiendo. El trabajo del agente es asegurarse de que la próxima medición que tomes sea la que elimina más ramas. ### ¿En qué sigue fallando? En todo lo que la documentación no contiene. Una placa sin esquemático y sin boardview le deja tus fotos, tus mediciones y conocimiento general de electrónica, que es una ayuda real pero mucho más delgada. Tampoco puede ver una soldadura fría ni oler algo quemado. Y no va a saber que este lote exacto de placas tiene un pad débil conocido a menos que alguien lo haya registrado.