La proximidad importa sobre todo al mapear procesos: reunir a negocio, operaciones e IT, observar excepciones y asignar responsables. Después, la implementación se apoya en fuentes, permisos, integración, evaluación y operación documentados. Estas son las capacidades con las que podemos continuar el proyecto. Para proyectos del Maresme o el Barcelonès Nord, consulta también el enfoque local de Mataró y Badalona.
Una implementación fiable mezcla piezas distintas: software determinista para reglas previsibles, modelos cuando el lenguaje o la ambigüedad importan, recuperación de conocimiento cuando la respuesta debe apoyarse en fuentes y supervisión humana cuando el coste del error exige criterio. El objetivo no es maximizar la cantidad de IA, sino diseñar el sistema que mejor resuelve el trabajo.
Describe tarea, sistemas y responsable, y añade una excepción que hoy genera trabajo. Definimos el alcance de revisión y el entregable antes de cerrar el siguiente encargo.
En Barcelona y área metropolitana una misma capacidad de IA cambia según la fuente de verdad, los permisos y el coste del error. Seleccionamos los sectores donde procesos transversales entre negocio, operaciones, marketing, producto e IT suelen crear casos especialmente claros, sin convertir la ciudad en una plantilla genérica.
Funciones de IA integradas en producto con identidad, permisos, observabilidad, evaluación, coste por tarea y evolución de modelo.
Copilotos, búsqueda y automatización para equipos que analizan información, producen entregables y gestionan clientes o expedientes.
Catálogo, atención, contenido y operaciones conectadas con ecommerce, PIM, ERP, CRM y helpdesk sin inventar stock, precio o estado.
Alcance, presencialidad, integración, métricas y límites para que el primer proyecto responda a un proceso real y no a una moda tecnológica.
Depende del alcance, pero debería dejar como mínimo un mapa de procesos y oportunidades, criterios de priorización, dependencias de datos e integración, riesgos, arquitectura propuesta, métricas y un siguiente paso concreto. Cuando procede añadimos especificación de piloto y casos de prueba. El objetivo es que una decisión pueda pasar a ejecución sin reinterpretar un deck genérico.
Las personas que conocen el proceso y quienes responden por sistemas, datos o resultado. No hace falta llenar una sala de perfiles senior: suele ser más útil combinar al owner operativo con IT/producto y, cuando afecta a clientes o negocio, la persona responsable de esa decisión. La consultoría pierde calidad si sólo habla con quien compra la tecnología pero no con quien usa el flujo.
Puede ser una sesión de diagnóstico para acotar una oportunidad o un trabajo de varias semanas cuando hay procesos, equipos y sistemas distintos que ordenar. El plazo depende de acceso a información y complejidad, no del número de modelos que queramos evaluar. Si ya existe un caso claro, preferimos llegar antes a una prueba medible que alargar la fase estratégica.
Podemos separar ambas fases, pero CODE-IA está preparada para continuar con la construcción: automatización, agentes, RAG, integraciones y desarrollo a medida. Esa capacidad condiciona cómo recomendamos desde el principio: una arquitectura tiene que ser operable, evaluable y mantenible, no sólo correcta en una presentación.
Sí. La presencialidad tiene especial sentido para discovery, workshops de proceso y sesiones donde deben alinearse negocio, operaciones e IT. Después mantenemos decisiones, casos de prueba y seguimiento documentados para que desarrollo y QA no dependan de coincidir físicamente.
Incluimos la capa técnica y operativa que afecta al diseño: inventario de uso, proveedores, datos, permisos, supervisión, trazabilidad y evidencias. Cuando una cuestión requiere interpretación jurídica concreta, debe revisarla el equipo legal o de compliance correspondiente. Ver gobernanza de IA.