2. Buscando soluciones¶

3. ¿De qué va este tema?¶

Convertirás la propuesta inicial en un diseño conceptual: qué datos necesita, de dónde vienen, dónde se tratan y cómo se conectan dispositivos, servicios y aplicaciones.

Aprovecharemos para usar OpenCode como ejemplo observable de un sistema de agentes: cliente local, agente, proveedor, LLM, tool calling y herramientas. Ese mismo flujo te servirá para entender la nube, las API, la ejecución local, la IA, la privacidad y la continuidad del servicio.

Y para incluirlo en tu propia caja de herramientas y trabajar sobre tu proyecto

4. Clases¶

4.1. Preparar datos y contexto del proyecto¶

El material de partida también es un dato:
1. Tus notas en papel escaneado, la propuesta de UD1 en texto y los documentos autorizados son la materia prima del diseño.
2. Antes de usarlos con cualquier IA, revisa que no contienen datos personales, credenciales, información confidencial ni material con licencia restringida.
3. Si el escaneo es una imagen o PDF, comprueba qué entrada admite tu herramienta; si no la admite, conviértelo a texto con un OCR autorizado.
4. Conserva original, versión de trabajo y versión generada para poder contrastar y corregir.
Dato e información:
1. Un dato es un registro aislado: 42 %, parcela B, 10:15.
2. La información aparece cuando esos datos se relacionan con una finalidad: la parcela B está seca y necesita riego.
3. Para cada dato conviene identificar origen, formato, frecuencia, calidad, responsable y uso previsto.
4. Si un dato no alimenta ninguna decisión, mejor no recogerlo.

Ciclo de vida del dato:

Etapa	Pregunta clave	Ejemplo en el caso de riego
Captura	¿Qué se mide y con qué precisión?	Sensor de humedad y temperatura de una parcela.
Validación	¿El dato es completo, plausible y tiene fecha?	Descartar una humedad negativa o una lectura sin marca de tiempo.
Tratamiento	¿Qué cálculo o regla lo convierte en información?	Media por parcela y comparación con el umbral de riego.
Uso	¿Qué decisión, aviso o visualización produce?	Alerta al operario o activación simulada del riego.
Conservación	¿Cuánto tiempo se guarda y para qué?	Histórico mensual de consumo, incidencias y resultados.
Eliminación	¿Qué se borra o anonimiza y cuándo?	Registros antiguos con nombres de operarios.

Big Data, ciencia de datos, aprendizaje automático, aprendizaje profundo, IA y LLM:
1. Big Data: datos cuyo volumen, velocidad, variedad o calidad dificultan el tratamiento habitual.
2. Ciencia de datos: proceso para convertir datos en decisiones mediante preguntas, preparación, análisis y validación.
3. Aprendizaje automático: modelos que aprenden patrones a partir de ejemplos.
4. Aprendizaje profundo: redes neuronales usadas en problemas complejos como visión, lenguaje o voz.
5. IA: concepto más amplio que incluye las técnicas anteriores y otras formas de automatizar decisiones.
6. LLM: modelo entrenado con grandes cantidades de lenguaje; puede resumir, clasificar o proponer estructuras, pero necesita datos, contexto y supervisión humana.
Objetivos habituales de la ciencia de datos en una empresa:
1. Explicar qué ha pasado.
2. Detectar anomalías o errores.
3. Predecir una demanda, un fallo o una necesidad.
4. Recomendar o automatizar una decisión.
5. Medir el resultado de un cambio.

Actividad

Reúne la propuesta de UD1 en texto y tus notas escaneadas u otro documento permitido.
Comprueba que no contienen información prohibida y separa original, versión de trabajo y salida.
Inventa seis datos relacionados con tu proyecto y explica qué información aportan.
Elige uno y recorre su ciclo de vida completo.
Indica un dato que no recogerías y justifica por qué.
Decide qué nivel de análisis basta: informe, regla simple, aprendizaje automático o IA.
Explica qué objetivo empresarial persigue ese análisis.

4.2. Anatomía de un agente como OpenCode¶

OpenCode es un agente de IA de código abierto y, sobre todo, un entorno que organiza el trabajo con agentes:
1. No es solo un chat: gestiona sesión, contexto, archivos, herramientas, permisos y proveedor del modelo.
2. En esta UD se usa para leer, estructurar, extraer, contrastar y criticar documentación.
3. No se usa para programar, desplegar servicios ni construir el prototipo; eso llegará en UD3.
4. La revisión humana es obligatoria: la IA puede omitir, interpretar mal o inventar contenido.

Componentes del sistema:

Componente	Función	Ubicación habitual	Ejemplo en tu proyecto
OpenCode (harness)	Mantiene la sesión, el contexto, las herramientas y los permisos.	Tu equipo	Lee `docs/entrada` y escribe en `docs/salida` con tu aprobación.
Agentes	Aplican un rol, unas instrucciones y unos límites.	Configuración local	Un agente de planificación analiza sin modificar archivos.
Proveedor	Recibe la petición, autentica y enruta al modelo elegido.	Nube o endpoint local	Conecta con un LLM remoto o con un servidor local.
LLM	Interpreta el contexto y genera texto o solicitudes de herramientas.	Nube o local	Extrae requisitos de tus notas y propone una estructura.
Tool calling	Pide usar una herramienta concreta con unos argumentos.	Lo propone el modelo y lo ejecuta el harness	Solicita leer un archivo antes de responder.
Herramientas	Leen, buscan, editan, ejecutan comandos o consultan la web.	Local o red	Comparan el texto original con la salida generada.

Flujo observable:

Usuario
  ↓
OpenCode / agent harness
  ↓
Agente con contexto, instrucciones y permisos
  ↓
Proveedor
  ↓
LLM
  ↓
Tool calling
  ↓
Herramientas locales, archivos, API o servicios cloud

El ciclo de tool calling:
1. OpenCode envía el contexto, las instrucciones y las herramientas disponibles.
2. El LLM responde con texto o con una solicitud estructurada para usar una herramienta.
3. El harness comprueba los permisos y ejecuta la acción localmente o llama a un servicio autorizado.
4. El resultado vuelve al modelo.
5. El modelo continúa, pide otra herramienta o produce la respuesta final.
Agentes y permisos:
1. Un agente primario mantiene la conversación principal; un subagente puede hacer una tarea especializada.
2. En la versión actual, Plan está pensado para analizar y Build para trabajar con herramientas completas.
3. Los permisos pueden permitir, preguntar o denegar lectura, edición, comandos, web y otras acciones.
4. Para este curso interesa empezar con un modo de análisis o solo lectura y aprobar manualmente cualquier cambio.
Qué puede aportar en esta UD:
1. Convertir notas y texto inicial en un índice, requisitos o inventario de datos.
2. Explicar qué componente del flujo intervino en cada respuesta.
3. Comparar dos versiones del diseño y listar diferencias relevantes.
4. Detectar afirmaciones que no aparecen en el original.
5. Proponer riesgos o lagunas que después deberás validar.

Actividad

Abre una carpeta de trabajo solo con documentos ficticios, propios, públicos o autorizados.
Selecciona proveedor y modelo en OpenCode; identifica si el modelo es remoto o local.
Usa un agente de análisis o solo lectura para leer el material y proponer un índice.
Observa qué herramientas solicita y qué permisos te pide.
Anota qué partes del contexto salen de tu equipo y qué partes se procesan localmente.
Contrasta la salida con el original y corrige al menos tres errores o lagunas.
Explica con tus palabras la diferencia entre OpenCode, proveedor, LLM, agente y herramienta.

4.3. Nube, local e híbrido en el flujo del agente¶

El ejemplo de OpenCode ya es una arquitectura real:
1. Local: harness, archivos, herramientas, permisos y registro de acciones.
2. Nube: proveedor, LLM remoto y servicios externos autorizados.
3. Híbrido: razonamiento remoto con ejecución y datos bajo control local.
4. Alternativa local: un servidor de modelos en tu equipo, como Ollama, accesible como proveedor compatible si el hardware y el modelo lo permiten.
API y servicio web:
1. Una API permite que dos aplicaciones se comuniquen y compartan funciones o datos.
2. Un servicio web expone esa capacidad a través de la red.
3. OpenCode llama a una API del proveedor; tu solución puede llamar a API de sensores, almacenamiento, mapas, pago o IA.
4. En cada integración conviene revisar autenticación, datos enviados, formato, coste, latencia y errores.
Computación en la nube:
1. Procesar datos.
2. Almacenar información.
3. Intercambiar mensajes entre componentes.
4. Ejecutar aplicaciones o servicios.
5. Publicar paneles y resultados.
6. Modelos habituales: IaaS (infraestructura), PaaS (plataforma) y SaaS (aplicación).

Arquitectura IoT y niveles de procesamiento:

Nivel	Función	Ejemplo en el caso de riego	Limitación habitual
Mist	Microcontrolador o sensor con capacidad mínima.	Medir humedad y descartar ruido.	Poca capacidad y mantenimiento disperso.
Edge	Gateway o equipo cercano al origen.	Validar datos y aplicar la regla de riego.	Energía, actualización y seguridad local.
Fog	Capa intermedia entre edge y nube.	Agrupar varias parcelas y guardar una caché local.	Coste y gestión de un servidor intermedio.
Cloud	Centro de datos remoto y escalable.	Histórico, panel web y análisis mensual.	Latencia, conexión y coste recurrente.
On-premise	Servidores propios de la empresa.	Datos críticos que no deben salir.	Inversión inicial y mantenimiento.

Modelo remoto, modelo local y arquitectura híbrida:

Alternativa	Ventajas	Límites	Uso razonable
LLM remoto por API	Sin inversión en hardware, modelos actualizados y puesta en marcha rápida.	Los datos salen del equipo; coste por uso, latencia y dependencia del proveedor.	Tareas complejas con datos no sensibles o anonimizados.
Modelo local	Mayor control de datos y funcionamiento sin proveedor externo.	Hardware, mantenimiento, contexto limitado y menor calidad en tool calling.	Datos sensibles, pruebas o continuidad sin nube.
Arquitectura híbrida	Combina herramientas locales, decisiones cercanas al origen y servicios cloud cuando aportan valor.	Más componentes y más superficie de seguridad.	La mayoría de proyectos reales.

Flujo típico de tu solución:
1. Captura en sensor o dispositivo.
2. Validación o decisión cerca del origen.
3. Envío a un servicio, cola o API.
4. Almacenamiento y análisis en la nube o en un servidor local.
5. Consulta desde una aplicación web o multiplataforma.
6. Visualización, alerta o acción simulada.

Actividad

Sitúa cada pieza del flujo de OpenCode: qué es local, qué es nube y qué es híbrido.
Compara un proveedor remoto con un modelo local, real o conceptual: datos, coste, calidad, latencia y dependencia.
Sitúa cada función de tu proyecto en mist, edge, fog, cloud u on-premise.
Explica qué procesarías cerca del origen y qué enviarías a la nube.
Indica qué datos viajan por la red y cuáles contienen información sensible.
Dibuja un diagrama con componentes, flujos y una aplicación de consulta.
Justifica una API o servicio externo que integrarías y qué harías si no está disponible.

4.4. IA, herramientas y límites de confianza¶

IA aplicada a procesos:
1. Automatizar tareas repetitivas: clasificar documentos, preparar informes o responder consultas frecuentes.
2. Optimizar decisiones: riego, mantenimiento, rutas, inventario o consumo energético.
3. Detectar anomalías: lecturas imposibles, fraudes, fallos o intrusiones.
4. Asistir el desarrollo y la documentación: revisar requisitos, comparar versiones, sugerir pruebas o código.
Datos, valor y límites:
1. Sin datos suficientes y de calidad, no hay IA útil.
2. Una regla simple puede resolver problemas estables y conocidos.
3. La IA aporta valor cuando el patrón es complejo, cambia o depende de muchos factores.
4. Un LLM puede ayudar a redactar y comparar, pero no sustituye la evidencia del proyecto.
5. Hay que justificar beneficio, coste, mantenimiento y riesgo.
Sectores y lenguajes:
1. Sectores con implantación relevante: industria, agricultura, logística, salud, energía, finanzas, comercio y servicios digitales.
2. Python es el lenguaje más habitual en IA; también se usan R, Julia, Java, C++ y JavaScript para integrar servicios.
3. En DAW no siempre se entrena un modelo: muchas veces se consume un servicio o API de IA y se integra en la aplicación.

Seguridad, privacidad y confianza:

RGPD y LOPDGDD: minimización, finalidad, conservación y derechos sobre datos personales.
Revisa qué contexto envías al proveedor: documentos, rutas, archivos abiertos y resultados de herramientas.
Protege credenciales y tokens; nunca los incluyas en documentos, instrucciones ni ejemplos.
Limita herramientas y permisos: lectura, edición, comandos, web y acceso fuera del proyecto.
Una inyección de prompt puede ocultar instrucciones en un documento, correo o web que el agente procesa.
El modelo puede alucinar: contrasta cada afirmación con el original, la norma o el dato real.
La continuidad responde a: ¿qué pasa si falla un sensor, la conexión, la nube, el proveedor o el modelo?

Riesgo	Dónde aparece	Consecuencia	Medida proporcionada
Lectura falsa del sensor	Captura	Decisión incorrecta de riego	Validar rangos y marca de tiempo
Datos personales en un documento escaneado	Entrada del agente	Envío indebido al proveedor	Anonimizar o usar datos sintéticos
Credencial visible en la carpeta	Herramienta de lectura	Fuga de acceso o coste indebido	Excluir secretos y denegar acceso
Instrucción oculta en contenido externo	Contexto o web	Acción no deseada del agente	Solo lectura, aprobación manual y revisar origen
Recomendación inventada del modelo	Salida	Diseño incoherente o riesgo ignorado	Contrastar con el original y decidir con criterio
Interceptación de datos del proyecto	Comunicación/API	Fuga o manipulación	Cifrado, autenticación y minimización
Acceso indebido al histórico	Almacenamiento	Pérdida de confidencialidad	Roles, permisos y registro
Caída del proveedor o de la nube	Servicio	Interrupción del análisis o de la supervisión	Alternativa local, caché o funcionamiento degradado

Actividad

Propón un uso de IA para tu proyecto y compáralo con una regla simple.
Indica qué parte de la solución usaría IA y qué parte no la necesita.
Configura una prueba segura: documentos permitidos, sin credenciales y con edición o comandos restringidos.
Identifica qué datos se envían al proveedor y cómo los minimizarías.
Si puedes, compara la misma tarea con un modelo remoto y uno local; si no, compara sus ventajas y límites de forma razonada.
Identifica tres riesgos en tu diagrama o flujo de agente y una medida para cada uno.
Explica qué ocurriría si la nube o el proveedor no están disponibles y cómo mantendrías un servicio mínimo.

4.5. Revisar y depurar la solución con agentes¶

Depurar aquí significa revisar el diseño, no el código:
1. Buscar datos sin finalidad, componentes sin función o conexiones imposibles.
2. Detectar decisiones sin justificación, riesgos sin medida o arquitectura sobredimensionada.
3. Separar lo que dice el documento de lo que realmente se podrá demostrar.
4. Preparar un flujo reducido y viable para UD3.

Checklist de revisión:

¿Cada dato tiene origen, finalidad, responsable y destino?
¿Cada componente tiene una función clara?
¿Dónde se procesa, almacena y consulta cada dato?
¿Qué integraciones o API existen y qué datos intercambian?
¿La IA está justificada por los datos y el problema?
¿Qué permisos, herramientas y datos usa el agente?
¿Los riesgos tienen consecuencias y medidas proporcionadas?
¿Qué supuestos y límites tiene el diseño conceptual?
¿Qué flujo pequeño se construirá o concretará en UD3?

Pregunta	Qué revisar	Señal de problema
¿Para qué existe este dato?	Relación entre dato, decisión y visualización.	Se recoge información que nadie usa.
¿Dónde se decide?	Ubicación de la regla o del modelo.	Todo se envía a la nube sin necesidad.
¿Cómo se integra?	API, servicios y formatos de intercambio.	Componentes dibujados pero sin conexión real.
¿Qué puede fallar?	Dispositivo, red, nube, proveedor externo y modelo.	Riesgos citados sin medida concreta.
¿Qué puede hacer el agente?	Herramientas, permisos y datos accesibles.	Edición o comandos permitidos sin supervisión.
¿Qué se hará después?	Un flujo reducido con entrada, decisión y salida.	Alcance tan grande que no se podrá demostrar.

Revisión asistida por agentes:
1. Usa un agente de análisis o solo lectura para no modificar el documento mientras revisa.
2. Pídele que compare dos versiones y liste mejoras, regresiones y datos sin respaldo.
3. Pídele una crítica de arquitectura: componentes, flujos, API, nube/local, IA y riesgos.
4. Pídele una revisión de seguridad y privacidad: datos enviados, permisos, secretos y continuidad.
5. Valida cada sugerencia antes de aceptarla y registra las aceptadas, modificadas y rechazadas.
Ejemplos de instrucciones:
- Compara la versión A y la versión B y señala qué decisión de diseño ha cambiado.
- Indica qué afirmaciones no están respaldadas por los documentos originales.
- Lista riesgos por componente y conexión, con consecuencia y medida proporcionada.
- No modifiques archivos; solo analiza y explica.

Actividad

Revisa tu diseño con la checklist anterior.
Usa un agente solo lectura para encontrar una incoherencia, un dato sin finalidad o una conexión ausente.
Valida tres sugerencias del agente y clasifícalas como aceptadas, modificadas o rechazadas.
Corrige un riesgo no tratado y explica el compromiso aceptado.
Selecciona el flujo viable que propondrás en UD3.

Test de autoevaluación

Actividad final integradora

Con OpenCode, convierte tu propuesta inicial y tus notas escaneadas en un documento de diseño más claro y presentable. Usa agentes para contrastar versiones, criticar la arquitectura y depurar conceptualmente la solución. Conserva las versiones y las decisiones aceptadas, modificadas o rechazadas. El enunciado detallado y la rúbrica se publicarán aparte.