Fra AI-prototype til produktionsklar software

Det er blevet let at bygge en AI-demo, der ser imponerende ud. Det svære begynder, når den skal bruges hver dag af rigtige mennesker, med rigtige kundedata og konsekvenser, hvis den tager fejl.

Springet fra prototype til produktionsklar AI handler derfor mindre om at finde en bedre prompt og mere om klassisk software engineering: data, integrationer, sikkerhed, test, drift, observability og tydeligt ansvar.

En prototype beviser en mulighed. Produktion skal bevise stabilitet

En prototype må gerne arbejde med et begrænset datasæt, manuelle trin og en udvikler, der holder øje med resultatet. I produktion ændrer kravene sig. Brugere forventer ensartet svartid, adgangskontrol, historik og en løsning, der fortsætter med at virke, når modeller, data eller eksterne API'er ændrer sig.

Det er en vigtig skelnen. Man bør ikke gøre prototypen unødigt tung. Men man bør heller ikke forveksle en god demonstration med et færdigt produkt.

1. Definér hvad et godt svar er

Traditionel software kan ofte testes med et entydigt forventet resultat. Generativ AI kan formulere forskellige svar på samme input. Derfor skal I definere kvalitet på en anden måde: Hvilke fakta skal være korrekte? Hvilke kilder må bruges? Hvornår skal løsningen sige, at den ikke ved det? Og hvilke fejl er acceptable?

Lav et fast evalueringssæt med realistiske opgaver og problematiske edge cases. Kør det igen, når prompts, modeller, retrieval eller datakilder ændres. Ellers bliver forbedringer let vurderet på mavefornemmelse.

2. Gør data og kilder eksplicitte

Hvis AI'en skal bruge virksomhedens viden, skal det være klart, hvor den kommer fra, hvem der ejer den, og hvor frisk den skal være. En løsning bør kunne håndtere manglende og modstridende data i stedet for blot at skjule problemet bag et overbevisende svar.

Det betyder ikke, at hele virksomhedens datalandskab skal ryddes op først. Start med de datakilder, den konkrete arbejdsgang afhænger af, og udvid derfra.

3. Byg AI ind i den eksisterende arbejdsgang

En separat chatbot er ikke altid et produkt. Værdien opstår ofte først, når AI kobles til CRM, ERP, dokumenter, sagsstyring eller det fagsystem, medarbejderen allerede arbejder i.

Her bliver almindelige integrationsspørgsmål centrale: API'er, rettigheder, transaktioner, retries, idempotens og hvad der sker, hvis et eksternt system er nede. AI ændrer ikke behovet for robust integration.

4. Begræns hvad modellen må gøre

Der er stor forskel på at foreslå en handling og at udføre den. En model, der opsummerer en sag, har en anden risikoprofil end en agent, der ændrer priser, sender mails eller opdaterer kundedata.

Brug mindst mulige rettigheder. Validér struktureret output. Kræv menneskelig godkendelse ved handlinger med stor konsekvens, indtil I har dokumentation for, at mere automatisering er forsvarlig.

5. Planlæg for fejl, modelskift og leverandører

Modeller og API'er ændrer sig. Priser og rate limits ændrer sig. Derfor bør modelvalg være en bevidst del af arkitekturen og ikke spredt tilfældigt gennem applikationen. Log modelversion, svartider, fejl og relevante kvalitetsmålinger, så problemer kan spores.

Det betyder ikke, at alle løsninger skal understøtte fem modelleverandører. Abstraktion har også en pris. Byg kun den fleksibilitet, der er en realistisk grund til at bruge.

6. Sikkerhed og governance skal være konkret

Spørg konkret: Hvilke data sendes til modellen? Hvor behandles og opbevares de? Hvem kan se prompts og logs? Kan brugeren få adgang til dokumenter gennem AI'en, som vedkommende ikke kan åbne i kildesystemet?

Governance behøver ikke starte som et stort udvalg og et dokument på 80 sider. Start med klare ejere, godkendte anvendelser, datakilder, adgangsregler og en procedure for fejl og ændringer.

7. Mål om løsningen faktisk skaber værdi

Antal prompts er sjældent et godt forretningsmål. Mål i stedet den arbejdsgang, I ville forbedre: tid pr. sag, svartid, fejlrate, konvertering, antal manuelle trin eller kvalitet vurderet af fagpersoner.

En dyrere model kan være billigst, hvis den reducerer efterkontrol. En billig model kan være bedst, hvis opgaven er enkel og volumen høj. Produktionsøkonomi skal måles på hele processen, ikke kun tokenprisen.

En praktisk produktions-checkliste

• Der findes et tydeligt forretningsmål og en ejer af løsningen.

• Kritiske use cases og fejlscenarier indgår i et fast evalueringssæt.

• Datakilder, adgang og opdateringsfrekvens er kendt.

• Handlinger og modeloutput valideres før de rammer forretningssystemer.

• Logs, fejl, svartid og omkostninger kan overvåges.

• Der er en plan for modelændringer, nedbrud og rollback.

• Persondata og fortrolige data behandles efter konkrete regler.

Produktionsklar betyder ikke perfekt

Man kan over-engineere AI lige så let som anden software. Målet er ikke at bygge alle sikkerhedsnet fra dag ét. Målet er at kende konsekvensen af fejl og bygge den robusthed, der passer til den konkrete anvendelse.

Den gode vej er ofte: prototype hurtigt, evaluer på realistiske data, integrér med den rigtige arbejdsgang og hærd løsningen trin for trin. Så bevarer I AI-prototypens tempo uden at sende et eksperiment direkte i produktion.

Har I en AI-prototype, der skal blive til rigtig software? Uptime Development kan hjælpe med arkitektur, integrationer, data, sikkerhed og den produktionsplatform, der skal ligge rundt om modellen.