Legal tech och AI i traditionella branscher – hur digitaliserar man med förtroendet kvar?

Det börjar i ett konkret arbetsmoment som människor upplever som problematiskt. Inte i att ledningen vill använda AI. Teamet behöver observera var information skrivs om, var klienten blir osäker, vilka dokument som saknas och vilka beslut som kräver professionellt omdöme. En process kan se ineffektiv ut för att den innehåller nödvändiga kontroller. Om produktteamet inte förstår skillnaden riskerar det att automatisera bort det som skapar kvalitet.

Jag vill därför samla juristen, administratören, klientperspektivet och tekniken runt samma karta. Vem gör vad, med vilken information och vilket ansvar? Vilka variationer förekommer? Därefter kan vi välja ett avgränsat problem, exempelvis insamling eller strukturering av underlag, och definiera hur en människa granskar resultatet. Det är mindre spektakulärt än en total automatisering men ofta mycket mer användbart.

Återkommande informationsinsamling, påminnelser, dokumentordning och tydlig statuskommunikation kan ofta förbättras. Teknik kan hjälpa en klient förstå vilka uppgifter som saknas och hjälpa professionella användare att hitta avvikelser. Den kan också skapa bättre överlämningar mellan roller. Men när fakta är ofullständiga, människor är oense eller ett beslut påverkar rättigheter och ansvar behövs ofta mänskligt omdöme och en tydlig ansvarig person.

Gränsen är inte statisk. En funktion som är ofarlig i ett internt arbetsverktyg kan bli riskfylld om resultatet presenteras direkt för en konsument som ett säkert svar. Därför måste teamet beskriva användningssituationen, inte bara modellen. Vem läser resultatet, vad tror personen att det betyder och vad händer om det är fel? De frågorna bör påverka designen från början.

Genom att komma in tidigt och hjälpa teamet förstå problemet, inte bara granska en färdig lösning. En jurist kan identifiera ansvarspunkter, vanliga undantag och ord som användaren riskerar att misstolka. Om de insikterna blir produktkrav går det ofta snabbare än att bygga om efter lansering. Juristen behöver samtidigt vara nyfiken på tekniken och skilja mellan verkliga krav och invanda arbetssätt.

Jag ser mig gärna som översättare mellan professionell vardag och produktutveckling. Jag kan ställa frågor om vad som måste vara korrekt, vad som kan vara vägledande och när användaren ska lämnas över till en människa. Den rollen ersätter inte specialistbedömning av exempelvis dataskydd, AI-reglering eller yrkesansvar. Rätt experter behöver kopplas in när den faktiska produkten och marknaden är tydliga.

Förtroende är att användaren förstår vad tjänsten gör, vilka uppgifter den använder och vem som ansvarar för nästa steg. Ett enkelt gränssnitt får inte dölja en osäker process. Om systemet bara ger generell information ska det framgå. Om en människa granskar materialet ska användaren veta när. Transparens om begränsningar är en del av produkten, inte en text som läggs i villkoren sist.

Förtroende byggs också i felhanteringen. Kan användaren rätta en uppgift, få kontakt med en person och förstå varför ett resultat ändrades? I känsliga ärenden kan ton och timing vara lika viktiga som effektivitet. En person som hanterar ett dödsbo vill inte bara ha en snabb checklista; personen behöver känna att systemet förstår när situationen kräver mänsklig kommunikation.

Med tydlig riskbedömning, avgränsning och mänsklig kontroll som passar konsekvensen. Teamet behöver veta vilka fel som kan uppstå, hur de upptäcks och om användaren kan förstå osäkerheten. En språkmodell kan formulera övertygande text även när underlaget är bristfälligt. Därför räcker det inte att resultatet låter professionellt. Källor, versioner, behörigheter och granskningssteg kan vara avgörande.

Jag är försiktig med att ge generella regler eftersom tekniken och regelverken utvecklas. Det viktiga är att någon har mandat att säga nej till en användning som inte kan förklaras eller kontrolleras. Juridisk och teknisk specialistkompetens behöver bedöma den konkreta lösningen, datan, leverantörerna och jurisdiktionerna. Produktens marknadsföring ska dessutom motsvara vad systemet faktiskt kan leverera.

Välj ett arbetsflöde med tillräcklig volym för att ge lärande men begränsad konsekvens om något går fel. Bestäm vem som får använda piloten, vilken data som är tillåten och hur resultatet jämförs med nuvarande arbetssätt. Mät inte bara sparad tid. Följ även fel, frågor, användarnas förståelse och hur mycket extra granskning tekniken skapar. Ibland flyttar en lösning bara arbetet till en annan roll.

Involvera användarna i utvärderingen och var öppen med att produkten testas. Efter piloten bör teamet kunna beskriva vilka fall som fungerar, vilka som ska stoppas och vad som krävs för säker skala. Ett positivt demoögonblick är inte ett införandebeslut. Verksamheten behöver även planera utbildning, support, ansvar och hur gamla arbetssätt avvecklas.

De talar ofta förbi varandra. Teknikteamet uppfattar juristen som någon som bara säger nej, medan juristen får se en nästan färdig produkt och förväntas godkänna allt på kort tid. Båda bilderna skapar försvar. Ett bättre samarbete börjar med gemensamma observationer och en ordlista. Vad betyder kvalitet, automatisering och rådgivning för respektive part? Vilka beslut är produktbeslut och vilka kräver rättslig bedömning?

Incitamenten måste också vara tydliga. En byrå kan vara rädd att effektivisering minskar intäkter, medan produktbolaget behöver bevisa snabb tillväxt. Om den spänningen inte diskuteras blir pilotprojektet politiskt. Parterna bör formulera hur bättre klientvärde, arbetstid och affärsmodell kan utvecklas tillsammans. Då blir tekniken ett gemensamt verktyg i stället för ett hot som den ena sidan försöker sälja till den andra.

Det beror på vem som får värdet och vem som tar risken. En verksamhet kan köpa licens, utveckla en pilot tillsammans eller bidra med branschkunskap mot särskilda villkor. Om parterna överväger delat ägande eller intäkter behöver de vara tydliga med immateriella rättigheter, data, kundrelation, support och vad som händer om samarbetet upphör. En vag idé om gemensam innovation räcker inte.

Jag föredrar att den första fasen har ett separat mål och budget. Då kan båda sidor lära sig utan att låsa hela framtiden. Om piloten visar verkligt värde kan den kommersiella modellen fördjupas med bättre information. Juridisk dokumentation ska följa affärsmodellen, men affärsmodellen måste först vara begriplig för människorna som ska leva med den.

Beskriv det specifika arbetsmomentet och vem som upplever problemet. Visa vad ni har observerat, inte bara vilken teknik ni använder. Förklara produktens aktuella nivå, vilken data som behövs och vad ni vill att jag bidrar med: problemförståelse, användarperspektiv, marknadsdialog, pilotstruktur eller strategiskt partnerskap. Säg även vilka specialistbedömningar som redan gjorts och vilka som återstår.

Jag är särskilt intresserad när teamet respekterar den professionella användaren och kan börja avgränsat. Skicka inte verkliga klientuppgifter eller känsliga dokument i en första kontakt. Om det finns en relevant koppling kan vi diskutera en arbetsform där affär, juridisk vardag och teknik får mötas utan att någon roll låtsas kunna allt.