I første versjon av Kai, saksbehandlingsløsningen vår, gjorde vi det mange gjør: vi sendte alle dokumentene og alle reglene til en språkmodell og ba den vurdere saken. Det fungerte overraskende bra, helt til vi så at samme sak kunne få ulikt svar fra gang til gang. 

I Kai versjon to har vi snudd på det. Av 89 regler kjører nå 49 helt deterministisk på strukturerte registerfakta fra dataplattformen vår i Databricks, samt innsendte fakta fra dokumenter evaluert av Azure Content Understanding. 35 regler krever faglig skjønn og vurderes av en LLM som leser søknadsdokumentet. De siste 5 er hybride: de prøver deterministiske regler først, og slipper bare til KI når resultatene ikke strekker til. Alle resultater lagres med versjon, slik at vi kan etterprøve hvorfor systemet konkluderte som det gjorde. Erfaring har vist at resultatet er både mer forutsigbart, og mer presist enn det vi hadde. 

I foredraget forteller vi hvorfor vi gikk bort fra «alt til LLM», og følger én sak gjennom de tre regelsporene helt frem til grensesnittet der saksbehandleren tar den endelige beslutningen. Vi viser hvordan applikasjonen skiller mellom hva som er beregnet og hva som er vurdert av KI, og hvordan vi avgjør hvilken regeltype en regel skal ha. 

Foredraget passer for alle som vil ta i bruk KI i beslutningsprosesser uten å gi fra seg kontroll og sporbarhet. 

KI-valg blir ofte framstilt som et kompromiss mellom tre ting: kapabilitet, kostnad og sikkerhet, hvor du får lov til å velge to. Den enkleste veien er å skru på den kraftigste modellen for absolutt alt, og så sitte igjen med en skyhøy regning og GDPR-sensitive data på vei ut av Europa.

Vi mener trekanten ikke er en naturlov. Legger du til en fjerde akse, kompetanse, kan du flytte hele avveiingen. Du kan beholde høy kapabilitet samtidig som du øker sikkerheten og kutter kostnadene. En åpen modell kjørt i Europa, med et godt håndbygd harness rundt seg, slår ofte naiv bruk av en frontier-modell på alle tre dimensjonene på én gang.

I dette foredraget viser vi hvordan vi i Fraktal jobber med dette ute hos kundene. Vi tar med arkitektur, kodeglimt og konkrete løsninger, og vi forteller ærlig om både det som fungerte og det vi gikk på trynet med.

Hjelp! Vi skal også bli datadrevne, og vi trenger en dataplattform. Hva skal vi kjøpe? Databricks, Fabric eller Snowflake?» Jeg har sittet i mange kundemøter hvor det er for mye fokus på teknologi og for lite på eierskap og leveranseprosesser etc. Teknologien er sjelden problemet .. det vanskeligste å endre er folk og prosesser. 
 

Informasjonsarkitektur, er det magien som fikser alt? Fra sømløs datadeling til avansert kunstig intelligens.

Aidalos tilbyr løsninger for agentisk kunstig intelligens til industriell bruk. Eksempler på oppgaver vi løser er monitorering av bruer basert på sensordata og analyse av komplekse problemer basert på kundedata. Aidalos er allerede internasjonalt etablert gjennom et partnerskap med IBM.

Vi vil gi dere mer detaljer på hvilke problemer vi løser med agentisk KI og teknologivalg vi har tatt.

De fleste av oss trener flere ganger i uka. Vi bruker diverse trackingutstyr for å måle bl.a. intensitet og belastning og har tilgang til treningsplatformer som gir oss noe innsikt. Platformene er ganske gode på å gi oss fine visualiseringer av data, men feiler ofte på analyse og praktiske hints på hva resultatene praktisk betyr, og på å gi oss konkrete anbefalinger. Kan data science og GenAI hjelpe oss med dette? Først skal vi se hva som står bak typiske modeller som måler både intensitet og belastning i utholdenhetstrening. Videre skal vi gå gjennom et konkret oppsett som består av en AI-agent med verktøytilgang til treningsdata via MCP-servere, samt et sett med spesialiserte ferdigheter (agent skills). Til slutt skal vi se om vi med et slikt oppsett kan følge fremskritt og belastning over tid, og bruke det til å planlegge kommende treningsøkter.

Alle snakker om datakontrakter, men få har fått dem i produksjon. Denne sesjonen tar deg gjennom hva Open Data Contract Standard (ODCS) faktisk er, hvorfor og hvordan datakontrakter har blitt tatt i bruk i Kartverket og hvilke erfaringer vi har gjort oss underveis. Hvilke problemer løser datakontrakter - bidrar de til bedre datastyring, passer de i en dataprodukt-tilnærming, og hva er deres rolle når det er en språkmodell, ikke et menneske, som skal finne ut hva dataene dine betyr? Få innsikten du trenger for å avgjøre om du trenger datakontrakter i din organisasjon.

De siste årene har Zero-ETL, AI-drevet automatisering og utvikling endret hverdagen til data engineers. Jeg deler ærlige erfaringer: hva som faktisk fungerer, hva som er hype, og hva som er igjen av den tradisjonelle data engineer rollen i en verden der AI tar mer og mer plass.

Basert på intervjuer og forskningslitteratur gir jeg eksempler på hvordan folk setter opp bruken av KI-agenter i sine team og organisasjon for å skape verdi.

Vil virksomheten din være klar når KI blir en del av teamet?

KI-agenter er i ferd med å endre hvordan arbeid utføres, hvordan beslutninger tas og hvordan organisasjoner ledes. I dette foredraget utforsker vi hvordan menneske–agent-team fungerer, hvilke nye lederroller som vokser fram, og hvorfor evnen til å orkestrere mennesker og agenter kan bli morgendagens viktigste konkurransefortrinn.

Hva skjer når AI-agenten gjør alt riktig, men på sviktende grunnlag fordi data aldri kom frem?

Når stadig flere beslutninger og prosesser automatiseres, blir kvaliteten på dataflyten en del av selve beslutningsgrunnlaget. Likevel bygger vi fortsatt mange integrasjoner med en optimistisk antakelse om at nettverket er tilgjengelig, mottakeren svarer, og at data verken forsvinner, dupliseres eller blir forsinket underveis.

I dette foredraget deler jeg erfaringer fra arbeidet med Queuey i Trondheim og problemene vi møter når data skal bevege seg pålitelig mellom systemer, skytjenester og edge-enheter.

Vi ser på hva som faktisk skjer når forbindelser forsvinner, mottakere feiler, samme hendelse sendes flere ganger eller en enhet fortsetter å produsere data mens den er offline.

For en AI-agent kan én manglende hendelse bety at den tar en tilsynelatende riktig beslutning på et ufullstendig bilde av virkeligheten. Skal vi bygge mer autonome systemer, må vi derfor snakke like mye om hvordan data kommer frem som om hva AI-en gjør når den får dem.

Vi bygde en AI-agent for å søke og resonnere over et stort antall dokumentoppsummeringer. For å begrense søkeområdet for retrieval tok vi i bruk et emnefelt som allerede var automatisk generert av et annet, LLM-basert system som en del av oppsummeringsprosessen.

Ved nærmere inspeksjon oppdaget vi imidlertid at emnefeltene hadde betydelige kvalitetsproblemer: 40 % av dokumentene delte samme emne, det fantes duplikater med ulik bruk av store og små bokstaver, og totalt var det generert over 18 000 unike emner.

Agenten feilet aldri, og den flagget ingen problemer. Den gjorde ganske enkelt retrieval fra en skjevt fordelte dokumenter og leverte dårligere svar enn den burde ha gjort. Dette var en feil uten synlige symptomer.

I dette foredraget går vi gjennom caset i detalj: hvordan emnefeltet ble generert og brukt, hvordan kvalitetsproblemene faktisk så ut, og hvorfor de gikk under radaren. Deretter viser vi hvordan vi landet på en lovende, LDA-basert tilnærming, der foreløpige resultater fra et utvalg av dataene peker på noe for alle som bygger AI-pipelines:

Når output fra én modell brukes som input til en annen modell eller agent, bør denne outputen underlegges den samme kvalitetskontrollen som enhver annen datakilde. Og noen ganger er ikke den riktige løsningen en bedre modell, men en enklere og mer forutsigbar en.

Tech-ledere ser gang på gang at godt bygde løsninger stopper opp eller surner, fordi kunder og ikke-tekniske interessenter ikke ble tatt nok med i prosessen; forventningene ble aldri reelt avklart, og det tekniske teamet ble sittende alt for alene med å oversette gapet, som regel for sent.

Jeg har intervjuet 10 norske IT- og tek-bedrifter, og ingen av dem pekte på kode eller tekniske utfordringer som deres største problem. Samtlige trakk frem misforståelser og manglende forventningsavklaring mellom teknisk og ikke-teknisk som den egentlige prosjektdreperen.

Jeg er digital antropolog og grunnlegger av Fabrello Consulting, hvor jeg hjelper IT- og tech-bedrifter med å tette gapet mellom teknisk leveranse og kundens forventninger. Jeg brenner for at den menneskelige siden av teknologi skal komme først. Jeg har nylig skrevet en kronikk i Computerworld om teamet.

A Data Scientist who can perform a brilliant data analysis but is unable to communicate their results to decision makers will have limited impact. Therefore, training in skills such as visualization, message refinement, and customer relations can help them become more effective and lead to better data-driven decisions. Based on the presenter's experience writing a curriculum in Data Science, this talk discusses these skills and approaches to helping others learn them.

Generativ AI åpner nye muligheter for dataanalyse, men hvordan kan teknologien brukes på en måte som faktisk skaper verdi for dataanalytikere? I dette foredraget deler jeg erfaringer fra utviklingen av en AI-assistert analysearbeidsflyt, der AI brukes som støtte gjennom hele analyseprosessen – fra datakvalitet og dataforberedelse til statistisk analyse, tolkning og beslutningsstøtte. Jeg viser hvilke deler av arbeidsflyten som ga størst verdi, hvilke utfordringer vi møtte, og hvilke oppgaver som fortsatt krever menneskelig ekspertise. Målet er å gi deltakerne konkrete erfaringer og praktiske læringspunkter de kan ta med seg til egne data- og AI-prosjekter.

Alle som har jobbet med data har nok tenkt tanken, hvis data kunne snakke, hva ville den sagt? 

Ville den: 
* Avsløre de dårlige innputene som finnes?
* Advart deg mot faren om å bruke fritekstfelter?
*Sladret på Roger i Finans?
* Fortalt deg at id fra Ordre-tabellen ikke faktisk samsvarer med ord_id i Faktura som du trodde?

Det som er spennende nå, er at det faktisk ER mulig å snakke med dine data ved bruk av KI. 

Vi tar for oss tre forskjellige platformer, Microsoft Fabric med Warehouse, SnowFlake, og en mindre utfordrer MotherDuck.

Med disse tre tilbyderne ser vi på hvor enkelt det er å komme i gang med å snakke med dataen med din foretrukne KI.
Sammenligner hva som er forskjellene i oppsett og hva som er verdt å tenke på før man velger. 

I tillegg tar vi en titt på de faktiske datasamtalene man kan ha, og finner potensielle fallgruver med tanke på struktur, transformering, og skills.