AI leverandør i Danmark
UnderStack er en dansk AI leverandør, der bygger AI ind i konkrete arbejdsgange: udtræk af data fra dokumenter, svar ud fra intern viden og automatisering af gentagne trin, med cloud- eller lokale modeller og et menneske ved roret.
Hvis du foretrækker at tale om flere detaljer, finder vi gerne et tidspunkt, der passer.
01
AI er nyttig dér, hvor medarbejdere bruger timer på arbejde, der gentager sig, men ikke er regelmæssigt nok til klassiske regler. En bogholderiafdeling taster leverandørfakturaer ind, som kommer i tyve forskellige opsætninger. Et forsikrings- eller vurderingsfirma læser lange rapporter for at finde de samme ti oplysninger. En supportafdeling svarer på de samme spørgsmål ud fra en manual, ingen kan søge i. En salgsafdeling skriver tilbud om ud fra gamle tilbud. Et køkken taster følgesedler ind i lageret i hånden. I alle tilfælde kan en model tage første gennemgang: læse, udtrække, sortere, skrive udkast eller søge. Derefter kontrollerer og godkender et menneske. Vi bygger ikke chatbots for chatbottens skyld. Vi leder efter en arbejdsgang med målbar friktion og bygger den mindste automatisering, der fjerner den.
02
De fleste brugbare AI-løsninger er almindelig software med en model i et eller to trin. Det er softwaren omkring modellen, altså rettigheder, kontrolskærme og logning, der gør løsningen sikker at bruge i en virksomhed.
03
Hvor modellen kører, er lige så meget en forretningsbeslutning som en teknisk. Hostede modeller er den hurtigste vej i gang og passer, når indholdet må forlade jeres miljø under en databehandleraftale. Lokale modeller kører på jeres egne computere eller enheder, så dokumenter og samtaler aldrig forlader dem. Vi arbejder med begge dele. UnderStack Code, vores assistent til Mac, kører lokale modeller gennem Ollama og holder samtaler og filer på maskinen, og UnderStack Pocket AI er designet til at køre på selve Android-enheden. Før noget bliver bygget, beskriver vi, hvilke data der ville blive sendt hvorhen, så beslutningen er jeres.
04
AI-projekter fejler, når de tager udgangspunkt i teknologien. Vores begynder med én arbejdsgang og rigtige eksempler fra den.
05
Applikationen omkring modellen bygges i React, TypeScript og Node.js som vores øvrige software, så en AI-funktion kan ligge inde i et eksisterende system i stedet for i et separat værktøj. Modeller bruges gennem et API eller kører lokalt med Ollama. Tre beslutninger bliver truffet udtrykkeligt i hvert projekt. For det første hvad modellen må gøre uden godkendelse: I vores egne produkter venter ændringer, kommandoer og andre handlinger med konsekvenser på brugeren. For det andet hvilke data den må læse: Adgang gives pr. kilde og ikke samlet. For det tredje hvad der logges, så et automatisk trin kan efterprøves bagefter. Selve modellen behandles som en udskiftelig komponent, fordi der kommer bedre og billigere modeller med få måneders mellemrum.
06
Sprogmodeller er gode til at læse, opsummere og skrive udkast. De er upålidelige til præcis regning, til fakta, de ikke har fået, og til at sige, at de ikke ved noget. En veldesignet løsning tager højde for det. Tal bliver beregnet af almindelig kode, svar bygger på jeres egne dokumenter med kilden vist, og alt, der ændrer data eller forlader virksomheden, går forbi et menneske først. Kræver en arbejdsgang et svar, der er rigtigt hver gang uden kontrol, er en model det forkerte værktøj, og så er almindelig software det bedre valg. Det siger vi i den første samtale og ikke efter prototypen.
07
Et AI-projekt har to omkostninger: at bygge automatiseringen og at køre modellen. Den første afhænger af arbejdsgangen, kontrolskærmene og integrationerne. Den anden afhænger af mængden, og om modellen er hostet eller lokal. Fordi prototypen bliver kørt på jeres eget materiale, ser I kvaliteten og et skøn over driftsprisen, før I binder jer. Vi offentliggør ikke prisintervaller. Artiklen om AI-løsninger til danske virksomheder beskriver, hvordan man vælger den første arbejdsgang.
Til at læse og udtrække data fra dokumenter, sortere og fordele henvendelser, skrive udkast og opsummeringer og søge i intern viden. Den virker bedst som første gennemgang, som et menneske godkender.
Se efter en partner, der først forstår arbejdsgangen og kan tage ansvar for integration, sikkerhed, brugeroplevelse og drift. En god løsning behøver ikke begynde stort. Den skal kunne måles og bruges i hverdagen.
Kun hvis I vælger en hostet model, og så ved I på forhånd, hvilke data der sendes og til hvem. Med lokale modeller bliver dokumenter og samtaler på jeres egne maskiner.
Nej. De fleste automatiseringer bruger eksisterende modeller og kræver et sæt rigtige eksempler at teste på, ikke et træningsdatasæt. Et mindre antal repræsentative dokumenter er nok til en første prototype.
Prototypen bliver målt på jeres eget materiale, også på de tilfælde, hvor den fejler. I drift kontrollerer et menneske resultatet dér, hvor en fejl har betydning, og undtagelser bliver logget.
Ofte ja. Har det eksisterende system et API eller en database, vi kan nå, kan automatiseringen læse derfra og skrive tilbage, så teamet arbejder videre i samme værktøj.
