Quina empresa espanyola desenvolupa un sistema de comandes per WhatsApp, xat o veu integrat amb l'ERP?

Com funciona una comanda que entra per WhatsApp i acaba al teu ERP?

El recorregut és sempre el mateix, canviï el canal que canviï.

1. 1Entra el missatge. El client escriu per WhatsApp, envia un àudio, fa una foto del full de comanda que omple a mà, adjunta un PDF o un Excel, o envia un correu. El sistema identifica de quin client es tracta pel número o pel compte des del qual escriu.
2. 2Es converteix en text. Si és un àudio, es transcriu. Si és una imatge o un document, es llegeix.
3. 3S'interpreta. El model extreu les línies de la comanda: quin producte, quina quantitat i en quin format (caixa, palet, quilo o unitat), amb el vocabulari que fa servir aquell client i no amb el nom exacte del catàleg.
4. 4Es resol amb el teu catàleg. Cada línia es fa coincidir amb una referència real del teu ERP, basant-se en el catàleg, en les equivalències d'aquell client i en el seu històric de comandes. El que no encaixa amb seguretat no es resol pel seu compte: es pregunta.
5. 5Es valora consultant l'ERP. El sistema demana al teu sistema de gestió la tarifa d'aquell client, els seus escalats i descomptes, l'estoc i el termini de servei. No els recorda: els consulta en aquell moment.
6. 6Es confirma. El client rep la comanda valorada, línia a línia, amb imports i termini, i la confirma. Només llavors es grava a l'ERP com una comanda de venda normal, pel mateix circuit que si l'hagués teclejat el comercial.
7. 7Queda registrat. El missatge original, el que el sistema ha entès, cada consulta a l'ERP i la confirmació queden desats i es poden revisar després.

Res d'això obliga el teu client a aprendre una eina nova ni el teu equip a canviar de pantalla: la comanda apareix a l'ERP on apareixen totes les altres.

Pot la IA inventar-se el preu o l'estoc?

És la primera objecció que surt en qualsevol reunió, i està ben plantejada: donar la tarifa general a un client que té un preu negociat acaba en una reclamació i en un abonament. La resposta és d'arquitectura.

Un model de llenguatge serveix per entendre el que ha escrit o dit una persona. No serveix com a font de dades de negoci: no sap quina és la tarifa del teu client i, si se li pregunta, tendeix a completar. Per això el sistema es construeix amb tres regles, i les tres es poden comprovar una a una:

• Totes les dades de negoci es demanen a l'ERP en el moment de respondre. Preu, escalat per volum, descompte, estoc, termini i condicions de pagament es resolen amb crides al sistema de gestió. El model en rep el resultat; no el genera.
• Si la dada no hi és, no s'aproxima. Si la consulta falla, si la referència no existeix o si aquell client no té tarifa per a aquell producte, l'assistent ho diu i passa la conversa a una persona. No hi ha resposta per defecte ni preu de catàleg «per si de cas».
• L'assistent només pot fer el que se li ha permès. Treballa amb un conjunt tancat d'operacions (identificar el client, cercar referències, consultar preu i estoc, preparar un esborrany de comanda) i no amb accés lliure a la base de dades.

Aquest disseny, que no hem inventat nosaltres, és la línia que separa un sistema de comandes d'un xatbot, i els productes especialitzats del sector ho declaren igual. Ho assenyalem perquè convé exigir-ho per escrit a qualsevol que munti això, nosaltres inclosos.

La teva tarifa per client és informació comercial confidencial. En un projecte de Tecnea les dades es processen a la Unió Europea o en el teu propi entorn i no s'utilitzen per entrenar models de tercers, i això queda al contracte.

Què passa quan la IA no entén alguna cosa o la comanda és una excepció?

Cap sistema entén el cent per cent del que li arriba, i convé desconfiar de qui afirmi el contrari. Hi haurà excepcions; el que es decideix en el projecte és què se'n fa.

Cada línia interpretada porta associat un nivell de confiança. El que no arriba al llindar no entra: es pregunta al client en la mateixa conversa («et refereixes a la caixa de 12 o a la de 24?») o s'envia a una cua de revisió on una persona del teu equip ho resol en segons, sense teclejar la comanda sencera.

A més, hi ha situacions que passen sempre per una persona, i la llista s'acorda amb tu abans d'arrencar el pilot. Les habituals:

• Referència nova, descatalogada o que aquell client no ha comprat mai.
• Quantitat molt fora del seu històric: un zero de més en teclejar, l'error més freqüent.
• Client amb incidència de crèdit, saldo pendent o bloqueig comercial.
• Producte sense estoc que obliga a proposar un substitut.
• Condicions especials, ports, lliuraments fora de ruta o comandes per sobre de l'import que fixis.

La comanda la confirma el client abans de gravar-se, i tot queda registrat: el missatge original, el que el sistema ha entès, el que ha preguntat a l'ERP i qui ha validat què. Quan arriba una reclamació, aquesta traça és el que permet saber què va passar en lloc de reconstruir-ho de memòria.

El més honest és dir-ho així: la revisió es manté i canvia qui tecleja. I la pregunta decisiva (quin percentatge de les teves comandes entra sense intervenció) no es pot respondre des de fora. Es mesura en el pilot, amb les teves comandes reals, i amb aquest número es decideix si es continua.

Teniu un cas real d'això i en quin punt es troba?

Un dels projectes que ja publiquem, sense anomenar el client, és exactament aquest: un portal de comandes B2B per a un distribuïdor majorista, amb assistent per veu i text per als seus clients, amb les referències, els preus i l'estoc resolts a través del seu sistema de gestió i mai inventats per la IA. L'assistent a més proposa: obre amb l'última comanda a preu d'avui i avisa del que el client va deixar de demanar; com es fa això sense inventar res és a pot la IA recomanar productes als meus clients?.

Està en fase de pilot, i convé dir-ho amb precisió: és un prototip demostrable, construït amb el catàleg i les tarifes reals del client, que serveix per validar requisits, processos i viabilitat tècnica abans de comprometre un desplegament. Encara no està en producció amb tota la seva base de clients ni integrat de manera productiva amb el seu ERP. Dir-ho d'una altra manera seria vendre't un recorregut que encara no hem acabat.

Tampoc no publiquem percentatges de millora. Quan existeixi una mesura feta sobre les dades de l'ERP del client i tinguem permís per publicar-la, es publicarà amb el seu mètode al costat. Mentrestant preferim que se'ns jutgi pel disseny del sistema (què decideix el model, què decideix l'ERP i què decideix una persona), que és el que sí que podem explicar amb detall en una reunió, i no per una xifra que ningú pot comprovar.

Per què WhatsApp i no una app de comandes pròpia?

Molts distribuïdors ja han pagat una app o un portal B2B que els seus clients gairebé no fan servir. El motiu gairebé sempre és que el client treballa amb deu proveïdors i no instal·larà deu aplicacions ni recordarà deu contrasenyes per demanar quatre caixes.

El canal que ja està instal·lat és un altre. Segons el Panell de Llars de la CNMC (dades del segon trimestre de 2025, publicades el 31 d'octubre de 2025; 5.176 llars i 8.709 individus, sobre persones que utilitzen Internet almenys setmanalment), WhatsApp és l'aplicació preferida per enviar missatges pel 93,9 % dels internautes espanyols. La CNMC és el regulador del sector: no ven programari ni serveis. El panell mesura persones, no empreses (no existeix una estadística pública equivalent del canal de comandes entre empreses), però qui fa la comanda en un bar, en una obra o en una botiga és una d'aquestes persones i ja té l'aplicació instal·lada.

I la comanda manual continua sent la norma. L'INE, en la seva enquesta sobre l'ús de TIC i comerç electrònic a les empreses (dades de 2024, publicades el 22 d'octubre de 2025), situa en el 26,6 % les empreses espanyoles de deu o més empleats que van vendre per comerç electrònic. En aquesta enquesta només compta com a comerç electrònic la comanda rebuda per web, per aplicació o per missatge de tipus EDI: la comanda escrita a mà en un correu electrònic queda fora. És a dir, al voltant de tres de cada quatre no van rebre cap venda per un canal dissenyat per recollir comandes; allà la comanda arriba per telèfon, per correu o a través del comercial, i algú la tecleja.

El portal B2B no es retira: es queda per al client que ja l'utilitza i l'assistent dona entrada pel canal que fa servir la resta. Els dos acaben al mateix lloc, que és el teu ERP.

Com s'integra amb el meu ERP i què cal per part meva?

La integració es tria segons el que permeti el teu ERP, no segons el que sigui més còmode de programar. Aquestes són les vies, de la més estable a la menys.

I això és el que cal per part teva. Convé llegir-ho abans de demanar pressupost, perquè és el que decideix el termini: un catàleg amb referències, formats i equivalències, incloses les que fan servir els teus clients quan parlen («la garrafa de cinc», «el sac gros»); les tarifes, escalats i condicions per client dins del sistema —si el preu d'una part dels teus clients viu al cap d'una persona o en un full de càlcul, aquest és el primer treball, i és un treball de la teva empresa: la IA no pot consultar el que no hi és—; estoc consultable, encara que sigui amb el desfasament que ja tinguis avui; històric de comandes, perquè dotze mesos ajuden molt a encertar amb les equivalències de cada client; una persona del negoci com a referència, amb unes hores per setmana durant el pilot, que sol ser qui més sap de clients i no d'informàtica; contacte amb el fabricant o el partner que manté el teu ERP, amb permís escrit per accedir-hi; i, pel que fa al canal, un compte de WhatsApp Business Platform (l'API de Meta) i un número dedicat que no estigui en ús a l'aplicació normal de WhatsApp. La verificació del negoci a Meta no cal per començar a provar, però sí per aixecar els límits de missatges i de plantilles, així que convé tenir-la en marxa abans del desplegament.

I si el meu ERP no és a cap llista d'integracions?

Els productes del sector competeixen pel nombre d'integracions, i algun publica més de cinquanta ERP integrats amb noms coneguts. És un avantatge real si el teu ERP és a la llista.

El problema és que una part de la distribució espanyola de mida mitjana funciona amb verticals del sector, amb programari d'un fabricant local o amb un desenvolupament propi de fa anys, i no hem trobat cap llista pública d'integracions que els cobreixi. Aquest distribuïdor avui es queda sense resposta.

Tres preguntes decideixen si això és viable, sigui quina sigui la marca de l'ERP: es pot llegir el catàleg amb les seves referències i formats?, es poden llegir la tarifa de cada client i l'estoc?, es pot gravar una comanda per una via que el fabricant admeti? Si la resposta és sí, s'integra, encara que ningú ho hagi fet abans amb aquest sistema. Si és no, cal dir-ho abans de signar res.

Per això el pilot es fa sobre el teu sistema real i no sobre un document: la prova d'accés al teu ERP és de les primeres coses que es resolen, i si no hi ha via, se sap en setmanes i no en mesos.

Què passa amb els clients que continuen trucant per telèfon?

És el flanc que el sector sol esquivar, així que convé dir-ho clar: el telèfon no se substitueix. Hi ha tres maneres de tractar-ho, i les tres són legítimes.

• Deixar-ho com està i automatitzar la resta. És el més habitual en començar. El client que truca continua trucant; l'estalvi surt de tota la resta.
• Transcriure la trucada. La conversa es converteix en un esborrany de comanda amb les seves línies resoltes a partir del catàleg, i el comercial el confirma en lloc de teclejar-lo.
• Assistent de veu que atén i pren la comanda. És l'opció més exigent: cal informar que qui respon és un sistema d'IA i preveure el pas a una persona quan el client ho demani o quan aparegui una excepció.

Darrere d'aquesta pregunta sol haver-n'hi una altra: la por de perdre el tracte personal. És una por documentada, tot i que a la baula del costat. A l'estudi d'EY per a ConectadHos sobre digitalització a l'hostaleria (juny de 2024; 1.827 respostes recollides entre el 3 d'abril i el 21 de maig de 2024, distribuïdes a través de les mateixes empreses impulsores del projecte, és a dir, sense mostra aleatòria), el 19 % dels hostalers de zones rurals (que són, precisament, els clients d'una bona part dels distribuïdors) citen la por de perdre el contacte personal com a fre per digitalitzar-se. Mesura els teus clients, no tu. Convé a més saber qui ho publica: ConectadHos la formen Hostelería de España juntament amb Coca-Cola, Mahou San Miguel i Makro, és a dir, dos fabricants i un majorista que venen a aquest mateix canal i que es beneficien del fet que es digitalitzi; la dada del 19 % va, precisament, contra el seu interès.

La conclusió pràctica: l'objectiu és que la persona que avui atén el telèfon deixi de teclejar la resta.

Quant es triga a tenir-ho funcionant?

Els terminis són de calendari, no d'esforç, i compten des que hi ha accés real a les dades de l'ERP.

El que més els allarga és esperar que el fabricant de l'ERP concedeixi un accés, o que algú de la teva empresa confirmi com s'aplica de debò un descompte que fa anys que es fa «com sempre». Al pilot es treballa amb les comandes reals d'un grup petit de clients; el desplegament comença pels que demanen molt i tenen prou confiança per avisar si alguna cosa sembla estranya.

Quant costa i què no està inclòs?

El desenvolupament de l'aplicació completa costa a Tecnea entre 5.000 i 20.000 €, sense IVA, amb preu tancat per fase: una aplicació sobre un canal i sense integracions complexes parteix de 5.000 €, i una de completa, amb diversos canals, integracions i desplegament a tota la base de clients, arriba fins a 20.000 €. Abans, la prova de concepte (pilot) (aquí, l'entrada de comandes per un canal amb les teves comandes reals) parteix de 850 €. No cobrem un diagnòstic a part: la primera conversa no es cobra i la validació tècnica va dins del pilot. Després, una quota mensual des de 250 € durant la vigència del contracte inclou la infraestructura del servei, el compte amb el proveïdor d'IA, el manteniment i l'evolució. No hi ha llicències per usuari. El desglossament complet de què mou el preu és a quant costa una aplicació amb IA.

Preu tancat per fase vol dir que l'import de cada fase es fixa abans de començar-la i no depèn de les hores que hi dediquem. Si el pilot no convenç, s'atura allà i no es compromet el desplegament.

Sobre el cost del canal es pot ser precís, perquè la tarifa la publica el fabricant. Des de l'1 de juliol de 2025, WhatsApp Business Platform cobra per missatge i no per conversa. Des de l'1 d'octubre de 2026 cobra també les respostes que l'empresa envia dins de la finestra d'atenció al client que obre el mateix client en escriure, que fins llavors eren gratuïtes. Es paguen a la tarifa d'utilitat de cada país: a Espanya, 0,0166 € per missatge lliurat. El que escriu el client no es cobra (documentació i tarifa en euros de Meta per a desenvolupadors, verificades el 2 d'octubre de 2026). Una comanda porta unes poques respostes, així que el canal costa cèntims per comanda. Meta canvia aquesta tarifa amb certa freqüència: es comprova en pressupostar, no abans.

Sobre el cost dels models no donarem un rang manllevat. L'única dada pròpia i mesurada que podem ensenyar és d'un altre producte nostre: l'informe d'unes 26 pàgines que generava la primera versió de la calculadora d'aquesta web costava al voltant de 0,04 € d'IA per informe. Interpretar una comanda és un treball molt més curt que redactar aquest informe, i transcriure àudio té el seu propi cost. La xifra que compta és la teva: es mesura en el pilot i és el que ajusta el «des de» de la quota mensual, que inclou el compte amb el proveïdor d'IA. En un projecte es paga la integració amb el teu ERP, les regles del teu negoci i el manteniment; el consum del model queda en cèntims.

Quant s'estalvia de debò?

No existeix una dada espanyola fiable del cost de processar una comanda a mà. L'hem buscada. Les xifres que circulen (tants euros per comanda, tant per cent d'error) provenen dels mateixos proveïdors que venen la solució, sense mostra ni metodologia publicada. No les farem servir.

L'única referència institucional que hem localitzat és de GS1 UK amb la Cranfield School of Management, publicada al setembre de 2010 amb dades de 2009: situa en 14 lliures l'estalvi per comanda d'utilitzar EDI en lloc de processos manuals (telèfon, fax, correu postal i correu electrònic) en la distribució alimentària minorista britànica. Convé llegir-la amb els seus límits, que són grans: té setze anys, és britànica, la publica l'organisme que promou l'estàndard EDI i, sobretot, el mateix informe atribueix aquesta xifra a una investigació del sector realitzada a GS1 UK sense publicar-ne el mètode. El que sí que té mètode publicat en aquest informe és una altra cosa: l'enquesta als quinze minoristes més grans del Regne Unit que va mesurar el grau d'adopció de l'EDI (87 % de les comandes). Serveix per saber que la diferència entre comanda manual i comanda electrònica existeix i és significativa; no serveix per pressupostar el teu cas.

El que sí que es pot fer és calcular-ho amb els teus números, i no cal que ho fem nosaltres:

1. 1Compta les comandes que entren al mes per telèfon, WhatsApp i correu.
2. 2Cronometra el que es triga de debò a passar-ne una a l'ERP, incloses les anades i vingudes per aclarir una referència o un format.
3. 3Multiplica-ho pel cost real d'aquella hora per a l'empresa. Com a referència oficial, l'INE xifra el cost laboral total per hora efectiva en 24,88 € de mitjana en el conjunt d'activitats el primer trimestre de 2026 (Enquesta Trimestral de Cost Laboral). És el cost per a l'empresa, no un salari, i el teu el saps tu.
4. 4Suma el que avui et costen els errors: abonaments, devolucions, reenviaments i segones entregues. Aquesta dada ja és al teu ERP.
5. 5Descompta-hi el que continuarà fent una persona, perquè les excepcions no desapareixen.

Si el resultat no amortitza un projecte d'entre 5.000 i 20.000 € en un termini que et convenci, la conclusió honesta és que encara no toca. Ho direm igualment.

Cal avisar que respon una IA i qui respon si una comanda surt malament?

Són dues preguntes que en aquest sector gairebé ningú contesta a la seva web, i les dues tenen resposta amb la norma a la mà.

Avisar, sí. L'article 50.1 del Reglament (UE) 2024/1689, el Reglament europeu d'intel·ligència artificial, obliga els proveïdors a dissenyar els sistemes d'IA destinats a interactuar directament amb persones físiques de manera que aquestes persones estiguin informades que estan interactuant amb un sistema d'IA, tret que resulti evident per a una persona raonablement informada, atenta i perspicaç, tenint en compte les circumstàncies i el context d'utilització. És aplicable des del 2 d'agost de 2026. Un assistent que pren comandes per WhatsApp o per telèfon és de ple en aquest supòsit. A la pràctica es resol amb un avís en el primer missatge de cada conversa i a la fitxa del canal, i amb el registre que aquest avís es mostra. Qui figura com a proveïdor i qui com a responsable del desplegament depèn de com es posi en servei el sistema; es decideix i es documenta dins del projecte, i per això la documentació de compliment forma part del treball i no és un annex que s'envia al final.

Respondre, també, però per contracte. Aquí convé desfer un equívoc freqüent. La Directiva (UE) 2024/2853 sobre responsabilitat per productes defectuosos sí que considera producte els programes informàtics, inclosos els sistemes d'IA, i tracta com a fabricant el desenvolupador de programes i el proveïdor d'un sistema d'IA (article 4.1 i considerant 13); s'aplica als productes introduïts al mercat o posats en servei després del 9 de desembre de 2026 (article 2.1), data límit també perquè Espanya la transposi (article 22). Però no resol el teu cas: només empara persones físiques (article 5.1) i deixa fora els danys en béns utilitzats exclusivament amb finalitats professionals i les dades d'ús professional (article 6.1). Una comanda mal servida entre dues empreses és un dany patrimonial entre professionals, i això es dirimeix on sempre: al contracte. La conseqüència pràctica és que convé que quedi per escrit qui respon de què, amb quin límit, i que cada comanda tingui traça de què va entendre el sistema, què va preguntar a l'ERP i qui ho va confirmar.

Això no és assessorament jurídic. Ho documentem en cada projecte i és el que hauries de demanar a qualsevol proveïdor que et munti això. Sobre on viuen les dades i com es justifica el compliment, ho desenvolupa IA privada i conforme a la llei.

Què es lliura i de qui és?

El mateix que en qualsevol altre projecte de Tecnea, aplicat a aquest cas:

• Codi font, prompts, configuracions i documentació del desenvolupament específic del teu projecte, la propietat dels quals queda fixada al contracte a favor de la teva empresa.
• Infraestructura dedicada i compte amb el proveïdor d'IA, contractats i operats per Tecnea i inclosos en la quota mensual mentre dura el contracte. Les credencials del canal de WhatsApp i de l'ERP van a nom de la teva empresa des del primer dia.
• El mapa de la integració amb el teu ERP: què es llegeix, d'on, com es grava una comanda i què passa si el sistema no respon. Documentat, no al cap de ningú.
• Documentació tècnica completa del sistema, mantinguda al dia durant el contracte.
• Les teves dades són teves: allotjades a la Unió Europea o en el teu entorn, mai utilitzades per entrenar models de tercers.
• Sense dependència del proveïdor d'IA: l'aplicació canvia de model sense refer-se.
• Propietat intel·lectual i condicions de sortida definides al contracte, sense llicències per usuari.

Els components propis de Tecnea que fem servir en el teu projecte (la part de codi genèrica, ja construïda i provada en altres clients, que és el que permet aquest preu i aquests terminis) continuen sent de Tecnea i s'utilitzen dins del servei.

Què convé exigir per escrit a qualsevol proveïdor, nosaltres inclosos, és a què exigir al contracte a un proveïdor d'IA.

Em convé un producte de subscripció o un desenvolupament a mida?

Depèn del teu cas, i val la pena dir-ho encara que no sempre ens convingui.

Si la teva distribuïdora és d'hostaleria, el teu ERP és un dels habituals del mercat i les teves condicions comercials són estàndard, un producte espanyol especialitzat probablement et sortirà abans i més barat: hi ha productes per a distribució HORECA i per a distribució tècnica (climatització, lampisteria, bany, electricitat, construcció i ferreteria) amb integracions ja fetes, encara que cap dels que hem revisat publica preu (verificat el 9 de setembre de 2026). I si el fabricant del teu propi ERP ja ven una capa de comandes per WhatsApp, aquesta és la primera opció que hauries de mirar.

El desenvolupament a mida té sentit quan el teu ERP no està suportat per cap producte, quan les teves regles de preu o de servei no caben en un estàndard, o quan vols que el sistema sigui teu en comptes d'un lloguer. Com decidir-ho en cinc minuts, amb els casos en contra, és a programari a mida o producte de catàleg?; com treballem un projecte a mida, amb les seves fases i les seves garanties, a desenvolupament d'aplicacions que integren IA.

En lloc d'un catàleg de cinquanta integracions ja fetes, portem la capacitat de construir la teva sobre el teu procés, amb un equip sènior que treballa amb tu sense intermediaris. Si el que busques és una plataforma ja provada per centenars de distribuïdors i disponible la setmana vinent, un producte especialitzat encaixa millor.

Quan això no val la pena?

Hi ha casos en què la resposta correcta és esperar, i preferim dir-ho a la web abans que a la tercera reunió:

• Quan el volum no ho justifica. Si reps unes poques comandes al dia i les tecleja la mateixa persona en deu minuts, l'estalvi no paga el projecte. Fes el càlcul de l'apartat anterior abans de demanar pressupost.
• Quan el catàleg i les tarifes no són al sistema. Si el preu de cada client viu en un full de càlcul o a la memòria d'algú, primer cal ordenar-ho. És un treball previ, és teu i no el resol la IA.
• Quan el teu ERP ja ven aquesta capa. Si el fabricant ofereix comandes per WhatsApp i cobreix les teves regles, comença per aquí: és més barat i més ràpid.
• Quan el que busques és un producte llest i les teves condicions són estàndard. Un producte de subscripció encaixarà millor que un desenvolupament.
• Quan ningú del negoci hi pot dedicar temps. El pilot necessita unes hores per setmana de la persona que coneix els clients. Sense això, el sistema aprèn les regles equivocades.
• Quan s'espera que ningú no revisi mai res. Sempre hi haurà excepcions. Si aquesta expectativa no es pot canviar, el projecte es donarà per fracassat encara que funcioni.
• Quan els teus clients demanen gairebé tot per telèfon i no vols tocar aquest costum. Es pot transcriure, però el retorn serà menor i cal saber-ho abans de començar.

Això és per a la meva empresa?

Treballem amb distribuïdors majoristes, fabricants amb canal B2B i comerços que reben comandes per telèfon, WhatsApp i correu: empreses consolidades, amb catàleg ampli i tarifes diferents per client, en què la decisió la pren una sola persona, tinguin o no departament d'informàtica propi.

Si vols veure abans com s'aplica la IA al conjunt de la teva operació, i no només a l'entrada de comandes, tenim dues pàgines per sector: IA per a empreses de comerç i distribució i IA per a empreses de transport i logística. El marc general de com treballem, amb les fases i les garanties, és a consultoria i implantació d'IA per a empreses.

Som Tecnea, una empresa espanyola de desenvolupament de programari i implantació d'intel·ligència artificial per a empreses, fundada el 2016, amb seu a Madrid i oficina a Gijón, que atén empreses de tot Espanya.