Versioi promptit, mallit ja työnkulun logiikka yhtenä AI-julkaisuna

Turvallinen AI-julkaisu on koko käyttäytymiseen vaikuttava kokoonpano, ei pelkkä prompti tai mallipäätepiste. Mallin palauttaminen ei auta, jos muuttunut työkalu, käyttöoikeus, hakumääritys tai uudelleenyrityksen logiikka jää tuotantoon. Siksi yhdellä julkaisutunnuksella on voitava osoittaa, mitä kokonaisuutta arvioitiin, mikä kokonaisuus palveli yksittäisen pyynnön ja mikä yhteensopiva versio saa liikenteen, jos eteneminen pysäytetään. Komponenttien omat versiohistoriat säilyvät hyödyllisinä, mutta käyttöönottopäätöstä ei pitäisi joutua kokoamaan niistä jälkikäteen kiireisen häiriötilanteen aikana.

Mikä muodostaa yhden AI-julkaisun?

Yksi AI-julkaisu muodostuu kaikista riippuvuuksista, jotka voivat muuttaa käyttäjälle tarjottua käyttäytymistä, toimivaltaa, riskiä, kustannusta, viivettä tai havaittavuutta. NIST käsittelee AI-järjestelmän elinkaaren toimintoja keskinäisriippuvaisina ja suosittelee komponenttien, myös olennaisten kolmannen osapuolen ohjelmistojen ja tietojen, inventointia. Google Cloud puolestaan kuvaa tuotantojärjestelmän sisältävän mallikoodin lisäksi muun muassa määrityksiä, automaatiota, testausta, metatiedon hallintaa, palveluinfrastruktuuria ja seurantaa. Käytännön julkaisuraja on siis palvelukohtainen, mutta sen on seurattava todellisia vaikutusreittejä.

• Prompti ja sen ratkaistu versio tai sisältötiiviste
• Mallivedos sekä efektiiviset lämpötila-, pituus- ja muut päättelyasetukset
• Työkaluskeemat, käyttöoikeudet, hyväksynnät ja sallitut yhteydet
• Käytännöt, suojaukset sekä haku- ja kontekstimääritykset
• Työnkulun koodi, reititys, uudelleenyritykset ja siirtologiikka
• Syöte- ja tulosteskeemat, ajonaikaiset riippuvuudet sekä käyttäytymiseen vaikuttavat ympäristösidokset

Arviointiaineisto, automaattinen arvioija, rubriikki ja päätösraja eivät tavallisesti suorita tuotantopyyntöä, joten niitä ei tarvitse väittää ajonaikaisiksi komponenteiksi. Ne vaikuttavat kuitenkin siihen, saako ehdokas luvan edetä, ja siksi niiden versiot kuuluvat samaan julkaisutietueeseen varmistusaineistona. Uusi ehdokas tarvitaan aina, kun prompti, mallivedos, efektiivinen asetus, käytäntö, työkalusopimus, skeema, työnkulku, hakumääritys, riippuvuus tai käyttäytymistä muuttava ympäristösidos vaihtuu. Pelkkä komponentin oma muutosloki ei kerro, mikä yhdistelmä oli tuotannossa.

Miten käyttäytymispino sidotaan julkaisu­manifestiin?

Käyttäytymispino sidotaan jäädyttämällä ehdokasmanifesti, jonka tunnus ei enää muutu. Manifestiin merkitään julkaisutunnus, luontiaika, omistaja, kohdepalvelu, tila, pysäytysehdot, palautuksesta vastaava henkilö ja edellinen tunnetusti toimiva julkaisu. Jokaisesta komponentista tallennetaan vakaa viite, kuten versio, commit-tunnus, artefaktin tiiviste tai sisältötiiviste, sekä todella käytetyt asetukset. production- tai latest-alias on vain muuttuva osoitin: manifestin on sisällettävä sen julkaisuhetkellä ratkaistu kohde. Salaisuuksien arvot eivät kuulu manifestiin, mutta hyväksytyn yhteyden tunniste kuuluu.

• Ratkaistut prompti-, malli-, työkalu-, käytäntö-, työnkulku-, skeema- ja riippuvuustunnisteet
• Efektiiviset päättelyasetukset, reititysehdot, ominaisuuslipun tunnus ja hyväksytyt ympäristöyhteydet
• Yhteensopivuusehdot, mahdolliset migraatiot ja edellinen tunnetusti toimiva palautuskohde
• Linkit arviointiaineistoon, arvioijiin, tuloksiin, hyväksyntään, etenemissuunnitelmaan ja ulkoisten toimien korjausohjeeseen

MLflow havainnollistaa, miksi julkaisutason vedos tarvitaan: promptipohjan versio voi olla muuttumaton, mutta alias on muuttuva ja promptiin liitetty mallimääritys voi muuttua myöhemmin. Samalla MLflow voi tallentaa mallin yhteyden tiettyyn promptiversioon. OpenAI suosittelee mallivedoksen kiinnittämistä, koska promptikäyttäytyminen voi muuttua vedosten välillä, ja Google Cloud suosittelee jäljitettävyyttä koodin, komponenttien, ajojen, aineistojen, asetusten, skeemojen ja arviointitulosten välillä. Mikään näistä yksin ei muodosta koko manifestia, mutta yhdessä ne tukevat ratkaistujen viitteiden tallentamista.

Esimerkiksi support-assistant-r18 voi sitoa promptin p-42, mallivedoksen m-2026-07 asetuksineen, CRM-työkaluskeeman t-9, käyttöoikeuskäytännön policy-12, työnkulkuversion wf-a71, tulosteskeeman reply-6 ja ajonaikaisten riippuvuuksien lukituksen. Julkaisupaketti linkittää erikseen arviointikokonaisuuden eval-23 ja arvioijaversiot. support-assistant-r17 voidaan nimetä palautuskohteeksi vasta, kun uusien valinnaisten määräaika- ja eskalointikenttien yhteensopivuus on tarkistettu. Liikenneosuudet ja käyttöönottoajat tallennetaan linkitettyinä etenemistapahtumina, jotta manifestia ei tarvitse muuttaa jokaisessa vaiheessa.

Jos jokin voi muuttaa tarjottua käyttäytymistä tai sen hyväksymiseen käytettyä näyttöä, sillä on oltava ratkaistu tunniste julkaisutietueessa.

Mikä näyttö ratkaisee ehdokkaan etenemisen?

Ehdokas saa edetä vain, jos juuri sen täydellinen kokoonpano läpäisee soveltuvat sopimus-, käyttäytymis-, turvallisuus-, toimivalta- ja palveluportit. Julkaisutiedoissa kuvataan tavoiteltu käyttäytymismuutos, vaihtuneet riippuvuudet, vaikutuksen alaiset tilanteet ja rajapinnat, käyttöoikeus- tai havaittavuusmuutokset, tunnetut rajoitteet, jäännösriski, omistajat ja yhteensopiva palautuskohde. NIST suosittelee dokumentoituja ja toistettavia arviointimenetelmiä sekä nimenomaista päätöstä käyttöönoton jatkamisesta. Portti ei siis pääty pelkkään mittarilukuun vaan nimettyyn etene-, pidä- tai hylkää-ratkaisuun.

Yleinen malliarvio ei riitä työnkulkukohtaiseksi näytöksi. OpenAI suosittelee todellisista tilanteista kerättyjä esimerkkejä, harvinaisia mutta kalliita reunatapauksia, toimiala-asiantuntijoiden osallistumista ja automaattisten arvioijien auditointia. Google Cloud suosittelee ehdokkaan vertaamista nykyiseen versioon, tärkeiden segmenttien ja palvelurajapintojen tarkastamista sekä tulosten tallentamista metatietoihin. Yksi hyvä keskiarvo ei saa peittää olennaista sopimus-, turvallisuus-, toimivalta- tai segmenttikohtaista heikkenemistä. Myös aineisto, arvioija, rubriikki ja päätösrajat versioidaan, jotta tulkinnan muutos näkyy.

GitHubin käyttöönottoympäristöt ovat yksi esimerkki siitä, kuinka tarkastajat ja ulkoiset laatu- tai havainnointitarkastukset voidaan tehdä toimeenpantavaksi portiksi. Suuremman riskin muutoksessa tekijä ja hyväksyjä voidaan erottaa; pienessä vähäriskisessä palvelussa sama henkilö voi kantaa molemmat roolit. Olennaista on, että näyttö, päätös, omistaja ja mahdollinen poikkeus jäävät kirjatuiksi. Päätösrajat määritetään palvelun tavoitteiden ja riskien perusteella, ei kopioida toisesta järjestelmästä.

Miten sama ehdokas viedään tuotantoon?

Sama ratkaistu ehdokas viedään tuotantoon portaittain, ja jokainen liikenne- tai kohorttimuutos kirjataan siihen linkitetyksi käyttöönotto­tapahtumaksi. NIST suosittelee testausta ennen käyttöönottoa, käytönaikaista seurantaa ja käyttäytymisen osoittamista tuotantoa muistuttavissa oloissa. OpenAI muistuttaa, että ulkoiseen käyttöön tuleva julkaisu tarvitsee offline-arvioinnin lisäksi verkkokokeita. Google Cloud kuvaa testiympäristön tarkastuksia, savutestejä, rajattua kanariaa ja verkkovertaamista määräämättä kaikille sopivia liikenneosuuksia tai havaintoaikoja. Rajattu eteneminen pienentää altistusta, mutta ei todista täydellistä tuotantoturvallisuutta.

1. Aja varjo- tai ei-toiminnallinen toisto, kun se on mahdollista. Poista kirjoittavilta työkaluilta vaikutus tai käytä eristettyä ympäristöä; älä toista tuotantotoimia sokeasti.
2. Avaa ehdokas sisäiselle käyttäjäryhmälle ja säilytä ihmisen hyväksyntä kaikissa seurauksellisissa ulkoisissa toimissa.
3. Ohjaa pieni, pysyvästi sama tuotantokohortti ehdokkaalle ja vertaa tehtävä-, turvallisuus-, työkalu-, luotettavuus-, viive- ja kustannussignaaleja nykyiseen julkaisuun.
4. Laajenna altistusta vasta sovitun näytön ja havaintojakson jälkeen. Kirjaa kohorttisääntö, liikenneosuus, havaintoaika ja päätös muuttamatta manifestia.
5. Siirry täyteen liikenteeseen, pidä palautuskohde saatavilla sovitun ajan ja jatka julkaisutunnuksella merkittyä seurantaa.

Liikenneosuuden ennalta hyväksytty kasvattaminen ei yksin muodosta uutta ehdokasta. Jos sen sijaan prompti, malliasetus, työkalu, lupa, käytäntö, haku, työnkulku, skeema, riippuvuus tai pyyntökohtaista käyttäytymistä muuttava ympäristösidos vaihtuu, syntyy uusi julkaisutunnus ja uusi näyttöketju. Liikenneosuudet, otosvaatimukset ja havaintoajat valitaan palvelun riskin, liikenteen, havaitsemisviiveen ja päivystyskyvyn mukaan. Pysyvä kohorttijako ja julkaisutunnuksella merkityt jäljet parantavat vertailua, mutta varjoliikenne tai kanaria ei välttämättä paljasta harvinaisia tilanteita eikä edusta kaikkia käyttäjiä.

Milloin julkaisu pysäytetään, ja mitä palautuksen pitää palauttaa?

Julkaisu pysäytetään heti ennalta määritetyissä kovissa tilanteissa, ja palautus kohdistetaan koko yhteensopivaan tunnetusti toimivaan kokoonpanoon. Kovia pysäytysehtoja ovat turvallisuus- tai käytäntörikkomus, luvaton työkalutoiminta, olennaisen sopimuksen rikkoutuminen ja vakava luotettavuusvirhe. Muut heikkenemiset arvioidaan palvelukohtaisilla rajoilla. Epäselvä havainto voi vaatia tutkimustauon automaattisen palautuksen sijasta, mutta myös silloin päätöksellä pitää olla omistaja. NIST käsittelee käyttöönottoa jatka- tai keskeytä-riskipäätöksenä; käytännön hälytysrajoja se ei määrää.

• Tarkista palautuskohteen syöte- ja tulosteskeemat sekä nykyinen sovellustila.
• Varmista työkalusopimukset, käyttöoikeudet, reititys ja palveluntarjoajien saatavuus.
• Selvitä, estävätkö migraatiot tai jo tehdyt tilamuutokset aiemman kokonaisuuden käytön.
• Harjoittele liikenteen palautus ja sen jälkeiset validointitarkastukset ennen todellista häiriötä.

Google Cloud suosittelee edellisen palveluversion nopean ja turvallisen palauttamisen testaamista sekä edellisen version tallentamista käyttöönoton metatietoihin. Aiempi julkaisu ei silti ole automaattisesti yhteensopiva nykyisen tilan kanssa. Palautus vaikuttaa lisäksi vain tulevaan reititykseen: se ei poista lähetettyä viestiä, peru tietokantakirjausta, kumoa hyväksyntää eikä poista CRM-järjestelmään jo luotua tehtävää. Julkaisutunnuksella merkityistä jäljistä tunnistetaan pyynnöt ja ulkoisten toimien tunnisteet. Sen jälkeen erillinen, valtuutettu toimintaohje määrittää rajaamisen, täsmäytyksen, korjauksen, ilmoittamisen tai hyvittävän toimen.

Mikä tietue tekee AI-julkaisusta myöhemmin rekonstruoitavan?

AI-julkaisu voidaan rekonstruoida myöhemmin, kun pysyvä tietue yhdistää jäädytetyn ehdokkaan, päätösnäytön, hyväksynnät, käyttöönotto­tapahtumat ja lopputuloksen. Google Cloud suosittelee komponentti- ja putkiversioiden, suoritusaikojen, suorittajien, parametrien, artefaktien, arviointitulosten ja edellisen mallin osoittimen tallentamista. Generatiivisessa työnkulussa sama periaate ulottuu promptiin, malliasetuksiin, työkaluihin, lupiin, hakumäärityksiin, työnkulkuun ja skeemoihin. Tavoitteena on kokoonpanon ja päätöksen toistettavuus: tietue kertoo, mitä käytettiin ja miksi eteneminen hyväksyttiin, vaikka samaa mallivastausta ei saataisi uudelleen.

• Jäädytetty manifesti ja kaikki ratkaistut tunnisteet sekä asetukset
• Ympäristösidokset, yhteensopivuustulokset ja edellinen tunnetusti toimiva julkaisu
• Arviointiaineistojen, arvioijien, rubriikkien ja päätösrajojen versiot sekä tulokset
• Hyväksynnät, poikkeukset, kohorttisäännöt, liikenneosuudet ja käyttöönottoajat
• Julkaisutunnuksella merkityt jäljet, havainnot, palautustapahtumat ja lopullinen päätös

OpenAI Agents SDK:n jäljitys voi tallentaa generoinnit, työkalukutsut, siirrot, suojaukset, ajoitukset, hierarkian ja metatiedot. Julkaisutunnus on lisättävä jälkiin sovelluksessa, jotta tapahtumat voidaan kohdistaa palvelleeseen kokoonpanoon. Palveluntarjoajan pyyntötunniste ja sovelluksen oma jälkitunniste auttavat rajaamaan ongelmaa järjestelmärajojen yli. Täydellinen jälki ei kuitenkaan edellytä jokaisen promptin, työkalusyötteen, vastauksen tai asiakashyötykuorman säilyttämistä. Arkaluonteisten tietojen käsittely ja säilytys noudattavat organisaation päätöksiä, ja jäljityksestä voidaan jättää hyötykuormia pois.

Pienin hyödyllinen julkaisupaketti tunnistaa muuttumattoman ajonaikaisen ehdokkaan, sen versioidun arviointinäytön, vaiheittaiset päätökset ja yhteensopivan palautuskohteen. Sisältötiiviste, kiinnitetty mallivedos tai arkistoitu pyyntö ei silti takaa tavutarkkaa uusintaa stokastisesta tai isännöidystä AI-palvelusta. Kun julkaisu muuttaa arkaluonteisten tietojen käsittelyä, seurauksellisia käyttöoikeuksia, säänneltyä työnkulkua, säilytysvelvoitteita tai ulkoisten toimien korjaamista, organisaation pätevien turvallisuus-, tietosuoja-, laki-, tiedonhallinta-, riski- tai toimiala-asiantuntijoiden on ratkaistava vaatimukset erikseen.