¿Qué empresa española desarrolla un sistema de pedidospor WhatsApp, chat o voz integrado con el ERP?

¿Cómo funciona un pedido que entra por WhatsApp y acaba en tu ERP?

El recorrido es siempre el mismo, cambie el canal que cambie.

1. 1Entra el mensaje. El cliente escribe por WhatsApp, envía un audio, hace una foto de la hoja de pedido que rellena a mano, adjunta un PDF o un Excel, o envía un correo. El sistema identifica de qué cliente se trata por el número o la cuenta desde la que escribe.
2. 2Se convierte a texto. Si es un audio, se transcribe. Si es una imagen o un documento, se lee.
3. 3Se interpreta. El modelo extrae las líneas del pedido: qué producto, qué cantidad y en qué formato —caja, palé, kilo o unidad—, con el vocabulario que usa ese cliente y no con el nombre exacto del catálogo.
4. 4Se resuelve contra tu catálogo. Cada línea se casa con una referencia real de tu ERP, apoyándose en el catálogo, en las equivalencias de ese cliente y en su histórico de pedidos. Lo que no encaja con seguridad no se resuelve por su cuenta: se pregunta.
5. 5Se valora consultando el ERP. El sistema pide a tu sistema de gestión la tarifa de ese cliente, sus escalados y descuentos, el stock y el plazo de servicio. No los recuerda: los consulta en ese momento.
6. 6Se confirma. El cliente recibe el pedido valorado, línea a línea, con importes y plazo, y lo confirma. Solo entonces se graba en el ERP como un pedido de venta normal, por el mismo circuito que si lo hubiera tecleado el comercial.
7. 7Queda registrado. El mensaje original, lo que el sistema entendió, cada consulta al ERP y la confirmación quedan guardados y se pueden revisar después.

Nada de esto obliga a tu cliente a aprender una herramienta nueva ni a tu equipo a cambiar de pantalla: el pedido aparece en el ERP donde aparecen todos los demás.

¿Puede la IA inventarse el precio o el stock?

Es la primera objeción que sale en cualquier reunión, y está bien puesta: dar la tarifa general a un cliente que tiene un precio negociado termina en una reclamación y en un abono. La respuesta no es que el modelo sea muy bueno. La respuesta es de arquitectura.

Un modelo de lenguaje sirve para entender lo que ha escrito o dicho una persona. No sirve como fuente de datos de negocio: no sabe cuál es la tarifa de tu cliente y, si se le pregunta, tiende a completar. Por eso el sistema se construye con tres reglas, y las tres se pueden comprobar una a una:

• Todo dato de negocio se pide al ERP en el momento de responder. Precio, escalado por volumen, descuento, stock, plazo y condiciones de pago se resuelven con llamadas al sistema de gestión. El modelo recibe el resultado; no lo genera.
• Si el dato no está, no se aproxima. Si la consulta falla, si la referencia no existe o si ese cliente no tiene tarifa para ese producto, el asistente lo dice y pasa la conversación a una persona. No hay respuesta por defecto ni precio de catálogo «por si acaso».
• El asistente solo puede hacer lo que se le ha permitido. Trabaja con un conjunto cerrado de operaciones —identificar al cliente, buscar referencias, consultar precio y stock, preparar un borrador de pedido— y no con acceso libre a la base de datos.

Este diseño no es un hallazgo nuestro: es la línea que separa un sistema de pedidos de un chatbot, y los productos especializados del sector lo declaran igual. Lo señalamos porque conviene exigirlo por escrito a quien quiera que monte esto, nosotros incluidos.

Tu tarifa por cliente es información comercial confidencial. En un proyecto de Tecnea los datos se procesan en la Unión Europea o en tu propio entorno y no se usan para entrenar modelos de terceros, y eso queda en el contrato.

¿Qué pasa cuando la IA no entiende algo o el pedido es una excepción?

Ningún sistema entiende el cien por cien de lo que le llega, y conviene desconfiar de quien afirme lo contrario. Lo que se decide en el proyecto no es si habrá excepciones, sino qué se hace con ellas.

Cada línea interpretada lleva asociado un nivel de confianza. Lo que no llega al umbral no entra: se le pregunta al cliente en la misma conversación —«¿te refieres a la caja de 12 o a la de 24?»— o se manda a una cola de revisión donde una persona de tu equipo lo resuelve en segundos, sin teclear el pedido entero.

Además hay situaciones que pasan siempre por una persona, y la lista se acuerda contigo antes de arrancar el piloto. Las habituales:

• Referencia nueva, descatalogada o que ese cliente no ha comprado nunca.
• Cantidad muy fuera de su histórico: un cero de más al teclear, el error más frecuente.
• Cliente con incidencia de crédito, saldo pendiente o bloqueo comercial.
• Producto sin stock que obliga a proponer un sustituto.
• Condiciones especiales, portes, entregas fuera de ruta o pedidos por encima del importe que fijes.

El pedido lo confirma el cliente antes de grabarse, y todo queda registrado: el mensaje original, lo que el sistema entendió, lo que preguntó al ERP y quién validó qué. Cuando llega una reclamación, esa traza es lo que permite saber qué ocurrió en lugar de reconstruirlo de memoria.

Lo honesto es decirlo así: esto no elimina la revisión, cambia quién teclea. Y la pregunta que de verdad importa —qué porcentaje de tus pedidos entra sin intervención— no se puede responder desde fuera. Se mide en el piloto, con tus pedidos reales, y con ese número se decide si se sigue.

¿Tenéis un caso real de esto y en qué punto está?

Uno de los proyectos que ya publicamos, sin nombrar al cliente, es exactamente este: un portal de pedidos B2B para un distribuidor mayorista, con asistente por voz y texto para sus clientes, con las referencias, los precios y el stock resueltos contra su sistema de gestión y nunca inventados por la IA. El asistente además propone: abre con el último pedido a precio de hoy y avisa de lo que el cliente dejó de pedir; cómo se hace eso sin inventar nada está en ¿puede la IA recomendar productos a mis clientes?.

Está en fase de piloto, y conviene decirlo con precisión: es un prototipo demostrable, construido con el catálogo y las tarifas reales del cliente, que sirve para validar requisitos, procesos y viabilidad técnica antes de comprometer un despliegue. Todavía no está en producción con toda su base de clientes ni integrado de forma productiva con su ERP. Decirlo de otro modo sería venderte un recorrido que aún no hemos terminado.

Tampoco publicamos porcentajes de mejora. Cuando exista una medición hecha sobre los datos del ERP del cliente y tengamos permiso para publicarla, se publicará con su método al lado. Mientras tanto preferimos que se nos juzgue por cómo está diseñado el sistema —qué decide el modelo, qué decide el ERP y qué decide una persona—, que es lo que sí podemos explicar en detalle en una reunión, y no por una cifra que nadie puede comprobar.

¿Por qué WhatsApp y no una app de pedidos propia?

Muchos distribuidores ya han pagado una app o un portal B2B que sus clientes apenas usan. El motivo casi nunca es la aplicación: es que el cliente trabaja con diez proveedores y no va a instalar diez aplicaciones ni recordar diez contraseñas para pedir cuatro cajas.

El canal que ya está instalado es otro. Según el Panel de Hogares de la CNMC (datos del segundo trimestre de 2025, publicados el 31 de octubre de 2025; 5.176 hogares y 8.709 individuos, sobre personas que usan Internet al menos semanalmente), WhatsApp es la aplicación preferida para enviar mensajes por el 93,9 % de los internautas españoles. La CNMC es el regulador del sector: no vende software ni servicios. El panel mide personas, no empresas —no existe una estadística pública equivalente del canal de pedidos entre empresas—, pero quien hace el pedido en un bar, en una obra o en una tienda es una de esas personas y ya tiene la aplicación instalada.

Y el pedido manual sigue siendo la norma. El INE, en su encuesta sobre el uso de TIC y comercio electrónico en las empresas (datos de 2024, publicados el 22 de octubre de 2025), sitúa en el 26,6 % las empresas españolas de diez o más empleados que vendieron por comercio electrónico. En esa encuesta solo cuenta como comercio electrónico el pedido recibido por web, por aplicación o por mensaje tipo EDI: el pedido escrito a mano en un correo electrónico queda fuera. Es decir, en torno a tres de cada cuatro no recibieron ninguna venta por un canal diseñado para recoger pedidos; ahí el pedido llega por teléfono, por correo o a través del comercial, y alguien lo teclea.

El portal B2B no se retira: se queda para el cliente que ya lo usa y el asistente da entrada por el canal que usa el resto. Los dos acaban en el mismo sitio, que es tu ERP.

¿Cómo se integra con mi ERP y qué hace falta de mi lado?

La integración se elige según lo que tu ERP permita, no según lo que sea más cómodo de programar. Estas son las vías, de la más estable a la menos.

Y esto es lo que hace falta de tu lado. Conviene leerlo antes de pedir presupuesto, porque es lo que decide el plazo: un catálogo con referencias, formatos y equivalencias, incluidas las que usan tus clientes al hablar («la garrafa de cinco», «el saco grande»); las tarifas, escalados y condiciones por cliente dentro del sistema —si el precio de una parte de tus clientes vive en la cabeza de una persona o en una hoja de cálculo, ese es el primer trabajo, y es un trabajo de tu empresa: la IA no puede consultar lo que no está—; stock consultable, aunque sea con el desfase que ya tengas hoy; histórico de pedidos, porque doce meses ayudan mucho a acertar con las equivalencias de cada cliente; una persona del negocio como referencia, con unas horas por semana durante el piloto, que suele ser quien más sabe de clientes y no de informática; contacto con el fabricante o el partner que mantiene tu ERP, con permiso escrito para acceder; y, del lado del canal, una cuenta de WhatsApp Business Platform (la API de Meta) y un número dedicado que no esté en uso en la aplicación normal de WhatsApp. La verificación del negocio en Meta no hace falta para empezar a probar, pero sí para levantar los límites de mensajes y de plantillas, así que conviene tenerla en marcha antes del despliegue.

¿Y si mi ERP no está en ninguna lista de integraciones?

Los productos del sector compiten por el número de integraciones, y alguno publica más de cincuenta ERP integrados con nombres conocidos. Es una ventaja real si tu ERP está en la lista.

El problema es que una parte de la distribución española de tamaño medio funciona con verticales del sector, con software de un fabricante local o con un desarrollo propio de hace años, y no hemos encontrado ninguna lista pública de integraciones que los cubra. Ese distribuidor hoy se queda sin respuesta.

Lo que decide si esto es viable no es la marca del ERP. Son tres preguntas: ¿se puede leer el catálogo con sus referencias y formatos?, ¿se pueden leer la tarifa de cada cliente y el stock?, ¿se puede grabar un pedido por una vía que el fabricante admita? Si la respuesta es sí, se integra, aunque nadie lo haya hecho antes con ese sistema. Si es no, hay que decirlo antes de firmar nada.

Por eso el piloto se hace sobre tu sistema real y no sobre un documento: la prueba de acceso a tu ERP es de las primeras cosas que se resuelven, y si no hay vía, se sabe en semanas y no en meses.

¿Qué pasa con los clientes que siguen llamando por teléfono?

Es el flanco que el sector suele esquivar, así que conviene decirlo claro: el teléfono no se sustituye. Hay tres formas de tratarlo, y las tres son legítimas.

• Dejarlo como está y automatizar el resto. Es lo más habitual al empezar. El cliente que llama sigue llamando; el ahorro sale de todo lo demás.
• Transcribir la llamada. La conversación se convierte en un borrador de pedido con sus líneas resueltas contra el catálogo, y el comercial lo confirma en lugar de teclearlo.
• Asistente de voz que atiende y toma el pedido. Es la opción más exigente: hay que informar de que quien responde es un sistema de IA y prever el paso a una persona cuando el cliente lo pida o cuando aparezca una excepción.

Detrás de esta pregunta suele haber otra: el miedo a perder el trato personal. Es un miedo documentado, aunque en el eslabón de al lado. En el estudio de EY para ConectadHos sobre digitalización en hostelería (junio de 2024; 1.827 respuestas recogidas entre el 3 de abril y el 21 de mayo de 2024, distribuidas a través de las propias empresas impulsoras del proyecto, es decir, sin muestra aleatoria), el 19 % de los hosteleros de zonas rurales —que son, precisamente, los clientes de buena parte de los distribuidores— cita el temor a perder el contacto personal como freno a digitalizarse. Mide a tus clientes, no a ti. Conviene además saber quién lo publica: ConectadHos la forman Hostelería de España junto a Coca-Cola, Mahou San Miguel y Makro, es decir, dos fabricantes y un mayorista que venden a ese mismo canal y que se benefician de que se digitalice; el dato del 19 % va, precisamente, contra su interés.

La conclusión práctica es que el objetivo no es que nadie llame. Es que la persona que hoy atiende el teléfono deje de teclear el resto.

¿Cuánto se tarda en tenerlo funcionando?

Los plazos son de calendario, no de esfuerzo, y cuentan desde que hay acceso real a los datos del ERP.

Lo que más los alarga no suele ser el desarrollo. Es esperar a que el fabricante del ERP conceda un acceso, o a que alguien de tu empresa confirme cómo se aplica de verdad un descuento que lleva años haciéndose «como siempre». En el piloto se empieza por un grupo pequeño de clientes que pidan mucho y que tengan confianza suficiente para avisar si algo sale raro.

¿Cuánto cuesta y qué no está incluido?

El rango habitual de un proyecto de Tecnea es de 5.000 a 20.000 €, sin IVA, con precio cerrado por fase. Un piloto sobre un proceso —aquí, la entrada de pedidos por un canal— parte de 5.000 €. Una aplicación completa, con varios canales, integraciones y despliegue a toda la base de clientes, llega hasta 20.000 €. No cobramos un diagnóstico aparte: la primera conversación no se cobra y la validación técnica va dentro del piloto. El mantenimiento y la evolución son una cuota mensual desde 250 €, con la infraestructura del servicio incluida y sin permanencia. No hay licencias por usuario. El desglose completo de qué mueve el precio está en cuánto cuesta una aplicación con IA.

Precio cerrado por fase significa que el importe de cada fase se fija antes de empezarla y no depende de las horas que dediquemos. Si el piloto no aporta, se para ahí, y lo hecho hasta ese punto se queda contigo.

Sobre el coste del canal se puede ser preciso, porque la tarifa la publica el fabricante: desde el 1 de julio de 2025, WhatsApp Business Platform cobra por mensaje y no por conversación; los mensajes que no son plantilla son gratuitos dentro de la ventana de atención al cliente que abre el propio cliente al escribir, y las plantillas de utilidad entregadas dentro de esa ventana abierta también lo son (documentación de Meta para desarrolladores, verificada el 9 de septiembre de 2026). En un flujo de pedidos es el cliente quien inicia la conversación, así que la mayor parte del tráfico cae en esa ventana. Meta cambia esta tarifa con cierta frecuencia: se comprueba al presupuestar, no antes.

Sobre el coste de los modelos no vamos a dar un rango prestado. El único dato propio y medido que podemos enseñar es de otro producto nuestro: el informe de unas 26 páginas que genera la calculadora de esta web cuesta alrededor de 0,04 € de IA por informe. Interpretar un pedido es un trabajo mucho más corto que redactar ese informe, y transcribir audio tiene su propio coste. La cifra que importa es la tuya, sale del piloto y se te enseña con la factura del proveedor delante. Lo que se paga en un proyecto es la integración con tu ERP, las reglas de tu negocio y el mantenimiento, no los céntimos del modelo.

¿Cuánto se ahorra de verdad?

No existe un dato español fiable del coste de procesar un pedido a mano. Lo hemos buscado. Las cifras que circulan —tantos euros por pedido, tanto por ciento de error— proceden de los propios proveedores que venden la solución, sin muestra ni metodología publicada. No las vamos a usar.

La única referencia institucional que hemos localizado es de GS1 UK con la Cranfield School of Management, publicada en septiembre de 2010 con datos de 2009: sitúa en 14 libras el ahorro por pedido de usar EDI en lugar de procesos manuales —teléfono, fax, correo postal y correo electrónico— en la distribución alimentaria minorista británica. Conviene leerla con sus límites, que son grandes: tiene dieciséis años, es británica, la publica el organismo que promueve el estándar EDI y, sobre todo, el propio informe atribuye esa cifra a investigación de sector realizada en GS1 UK sin publicar su método. Lo que sí tiene método publicado en ese informe es otra cosa: la encuesta a los quince mayores minoristas del Reino Unido que midió el grado de adopción del EDI (87 % de los pedidos). Sirve para saber que la diferencia entre pedido manual y pedido electrónico existe y es material; no sirve para presupuestar tu caso.

Lo que sí se puede hacer es calcularlo con tus números, y no hace falta que lo hagamos nosotros:

1. 1Cuenta los pedidos que entran al mes por teléfono, WhatsApp y correo.
2. 2Cronometra lo que se tarda de verdad en pasar uno al ERP, incluidas las idas y venidas para aclarar una referencia o un formato.
3. 3Multiplícalo por el coste real de esa hora para la empresa. Como referencia oficial, el INE cifra el coste laboral total por hora efectiva en 24,88 € de media en el conjunto de actividades en el primer trimestre de 2026 (Encuesta Trimestral de Coste Laboral). Es el coste para la empresa, no un salario, y el tuyo lo sabes tú.
4. 4Suma lo que hoy te cuestan los errores: abonos, devoluciones, reenvíos y segundas entregas. Ese dato ya está en tu ERP.
5. 5Réstale lo que seguirá haciendo una persona, porque las excepciones no desaparecen.

Si el resultado no paga un proyecto de entre 5.000 y 20.000 € en un plazo que te convenza, la conclusión honesta es que todavía no toca. Lo diremos igual.

¿Hay que avisar de que responde una IA y quién responde si un pedido sale mal?

Son dos preguntas que en este sector casi nadie contesta en su web, y las dos tienen respuesta con la norma en la mano.

Avisar, sí. El artículo 50.1 del Reglamento (UE) 2024/1689, el Reglamento europeo de inteligencia artificial, obliga a los proveedores a diseñar los sistemas de IA destinados a interactuar directamente con personas físicas de forma que esas personas estén informadas de que están interactuando con un sistema de IA, salvo que resulte evidente para una persona razonablemente informada, atenta y perspicaz, teniendo en cuenta las circunstancias y el contexto de utilización. Es aplicable desde el 2 de agosto de 2026. Un asistente que toma pedidos por WhatsApp o por teléfono está de lleno en ese supuesto. En la práctica se resuelve con un aviso en el primer mensaje de cada conversación y en la ficha del canal, y con el registro de que ese aviso se muestra. Quién figura como proveedor y quién como responsable del despliegue depende de cómo se ponga en servicio el sistema; se decide y se documenta dentro del proyecto, y por eso la documentación de cumplimiento forma parte del trabajo y no es un anexo que se manda al final.

Responder, también, pero por contrato. Aquí conviene deshacer un equívoco frecuente. La Directiva (UE) 2024/2853 sobre responsabilidad por productos defectuosos sí considera producto a los programas informáticos, incluidos los sistemas de IA, y trata como fabricante al desarrollador de programas y al proveedor de un sistema de IA (artículo 4.1 y considerando 13); se aplica a los productos introducidos en el mercado o puestos en servicio después del 9 de diciembre de 2026 (artículo 2.1), fecha límite también para que España la transponga (artículo 22). Pero no resuelve tu caso: solo ampara a personas físicas (artículo 5.1) y deja fuera los daños en bienes utilizados exclusivamente con fines profesionales y los datos de uso profesional (artículo 6.1). Un pedido mal servido entre dos empresas es un daño patrimonial entre profesionales, y eso se dirime donde siempre: en el contrato. La consecuencia práctica es que conviene que quede por escrito quién responde de qué, con qué límite, y que cada pedido tenga traza de qué entendió el sistema, qué preguntó al ERP y quién lo confirmó.

Esto no es asesoramiento jurídico. Es lo que documentamos en cada proyecto y lo que deberías pedir a cualquier proveedor que te monte esto. Sobre dónde viven los datos y cómo se justifica el cumplimiento, lo desarrolla IA privada y conforme a la ley.

¿Qué se entrega y de quién es?

Lo mismo que en cualquier otro proyecto de Tecnea, aplicado a este caso:

• Código fuente, prompts, configuraciones y documentación en un repositorio propiedad de tu empresa.
• Infraestructura dedicada, contratada y operada por Tecnea e incluida en la cuota mensual, con acceso de administrador y traspaso a tus propias cuentas cuando lo pidas. Las credenciales del canal de WhatsApp y del ERP van a nombre de tu empresa desde el primer día.
• El mapa de la integración con tu ERP: qué se lee, de dónde, cómo se graba un pedido y qué pasa si el sistema no responde. Documentado, no en la cabeza de nadie.
• Documentación técnica y despliegue reproducible, para que otro equipo pueda continuar sin nosotros.
• Tus datos son tuyos: alojados en la Unión Europea o en tu entorno, nunca usados para entrenar modelos de terceros.
• Sin dependencia del proveedor de IA: la aplicación cambia de modelo sin rehacerse.
• Propiedad intelectual y salida definidas en el contrato, sin permanencia y sin licencias por usuario.

Qué conviene exigir por escrito a cualquier proveedor, nosotros incluidos, está en qué exigir en el contrato a un proveedor de IA.

¿Me conviene un producto de suscripción o un desarrollo a medida?

Depende de tu caso, y merece la pena decirlo aunque no siempre nos convenga.

Si tu distribuidora es de hostelería, tu ERP es uno de los habituales del mercado y tus condiciones comerciales son estándar, un producto español especializado probablemente te salga antes y más barato: hay productos para distribución HORECA y para distribución técnica —climatización, fontanería, baño, electricidad, construcción y ferretería— con integraciones ya hechas, aunque ninguno de los que hemos revisado publica precio (verificado el 9 de septiembre de 2026). Y si el fabricante de tu propio ERP ya vende una capa de pedidos por WhatsApp, esa es la primera opción que deberías mirar.

El desarrollo a medida tiene sentido cuando tu ERP no está soportado por ningún producto, cuando tus reglas de precio o de servicio no caben en un estándar, o cuando quieres que el sistema sea tuyo en vez de un alquiler. Cómo decidirlo en cinco minutos, con los casos en contra, está en ¿software a medida o producto de catálogo?; cómo trabajamos un proyecto a medida, con sus fases y sus garantías, en desarrollo de aplicaciones que integran IA.

Nuestros límites, para que no te los cuente otro: no traemos un catálogo de cincuenta integraciones ya hechas, sino la capacidad de construir la tuya; no publicamos todavía casos con cliente identificado ni mediciones de mejora auditadas por un tercero, ni reseñas verificadas en directorios independientes como Clutch o Google; y el proyecto lo hace un equipo senior que trabaja contigo sin intermediarios, no una estructura con turnos de guardia. Si lo que buscas es una plataforma ya probada por cientos de distribuidores y disponible la semana que viene, un producto especializado encaja mejor.

¿Cuándo esto no merece la pena?

Hay casos en los que la respuesta correcta es esperar, y preferimos decirlo en la web antes que en la tercera reunión:

• Cuando el volumen no lo justifica. Si recibes unos pocos pedidos al día y los teclea la misma persona en diez minutos, el ahorro no paga el proyecto. Haz la cuenta del apartado anterior antes de pedir presupuesto.
• Cuando el catálogo y las tarifas no están en el sistema. Si el precio de cada cliente vive en una hoja de cálculo o en la memoria de alguien, primero hay que ordenarlo. Es un trabajo previo, es tuyo y no lo resuelve la IA.
• Cuando tu ERP ya vende esa capa. Si el fabricante ofrece pedidos por WhatsApp y cubre tus reglas, empieza por ahí: es más barato y más rápido.
• Cuando lo que buscas es un producto listo y tus condiciones son estándar. Un producto de suscripción encajará mejor que un desarrollo.
• Cuando nadie del negocio puede dedicarle tiempo. El piloto necesita unas horas por semana de la persona que conoce a los clientes. Sin eso, el sistema aprende las reglas equivocadas.
• Cuando lo que se espera es que nadie revise nunca nada. Siempre habrá excepciones. Si esa expectativa no se puede cambiar, el proyecto se dará por fallido aunque funcione.
• Cuando tus clientes piden casi todo por teléfono y no quieres tocar ese hábito. Se puede transcribir, pero el retorno será menor y hay que saberlo antes de empezar.

¿Es esto para mi empresa?

Trabajamos con distribuidores mayoristas, fabricantes con canal B2B y comercios que reciben pedidos por teléfono, WhatsApp y correo: empresas consolidadas, con catálogo amplio y tarifas distintas por cliente, en las que la decisión la toma una sola persona y no hay departamento de informática propio.

Si quieres ver antes cómo se aplica la IA al conjunto de tu operación, y no solo a la entrada de pedidos, tenemos dos páginas por sector: IA para empresas de comercio y distribución e IA para empresas de transporte y logística. El marco general de cómo trabajamos, con las fases y las garantías, está en consultoría e implantación de IA para pymes.

Somos Tecnea, una empresa española de desarrollo de software e implantación de inteligencia artificial para pymes, fundada en 2016, con sede en Madrid y oficina en Gijón, que atiende a empresas de toda España.