Naglabas ang AWS ng reference design para sa Amazon Quick upang magtanong tungkol sa compliance sa malaking koleksiyon ng mga lease. Mahalaga rito ang mahigpit na paglilipat ng gawain: pumipili ang chat model ng nakapirming tool at ipinapaliwanag ang tugon nito; hiwalay na tinutukoy ng rules engine ang populasyon at nagpapasya sa bawat kaso. Inilalarawan sa post noong Oktubre 2 at sa sample repository ang proof of concept na pang-edukasyon, hindi isang napatunayang serbisyong legal para sa compliance.

Para sa engineer o pinuno ng compliance, ang tanong ay kung ang hangganang ito ay angkop sa pasyang sinusuri. Gumagamit ang sample ng mga sintetikong lease at inimbentong tuntunin at sipi. Ipinapakita ng mga halimbawang kabuuan ang nilalayong anyo ng output; wala silang sinasabi tungkol sa katumpakan sa mga totoong kontrata o batas.

Ang pangunahing pagbabago

  • Ano ang nagbago: Ginagawa ng sample ng AWS ang AI na kontroladong interface para sa mga nakapirming tool sa pagsusuri. Tinutukoy ng rules engine ang mga finding para sa enumeradong populasyon ng mga lease.
  • Bakit ito mahalaga: Nagbibigay sa mga tagasuri ang mga bersiyonadong tuntunin at resibo ng ebidensiya ng paraan upang siyasatin sa labas ng chat kung paano sinuri ang mga napiling rekord.
  • Ano ang dapat bantayan: Hindi napapatunayan ng resibo ang imbentaryo, pagkuha ng datos, o mga legal na tuntunin. Kailangang suriin ng mga gagamit ang mga input na ito, kung naiuugnay nang tama ang bawat aksiyon sa user, at ang performance gamit ang sarili nilang datos.

Unahin ang populasyon bago ang prompt

Maaaring itanong ng user sa Quick kung alin sa mga lease sa Texas ang lumalabag sa tuntunin tungkol sa late fee sa isang tinukoy na petsa. Inililipat ng Quick ang kahilingan sa sweep_compliance, isa sa anim na pinangalanang MCP operation. Ginagamit ng operation ang tinukoy na hurisdiksiyon at petsa upang piliin ang populasyon at mga naaangkop na bersiyonadong tuntunin. Hindi nagsusulat ng SQL ang model at hindi rin ito nagpapasya kung pumapasa ang isang sugnay. Inilalapat ng rules engine ang mga nakapirming operator ng paghahambing, at ipinapasa ang mga halaga ng tuntunin bilang mga parameter. Ayon sa AWS, hindi kumukonsulta sa model ang opisyal na sweep. Ipinapaliwanag dito ng AWS ang kontrata ng operation; inilalarawan naman ng repository ang implementasyon.

Mas makitid ang kahulugan ng iba pang tool. simulate_rule_change nagbibigay ng pang-eksplorasyong bilang para sa iminungkahing halaga nang hindi nagtatala ng mga finding. explore_clauses nagraranggo ng na-filter na sample ayon sa semantikong pagkakahawig at hindi nito masasagot ang “ilan?” get_finding kumukuha ng isang hanay ng ebidensiya; list_rules nagpapakita ng mga tuntuning may bisa sa isang petsa; check_connection sinusuri ang transport. Mahalaga ang pagkakaibang ito dahil hindi katumbas ng census ang sample ng mga kaugnay na sugnay.

Gumagawa ang sweep ng resibo na tumutukoy sa bawat na-scan na rekord sa isa sa apat na kategorya: sumusunod, lumalabag, malabo, o hindi mabasa. Tinitiyak ng engine na katumbas ng kabuuang na-scan ang kabuuan ng bilang na ito bago mag-commit. Maipapakita ng Quick ang mga bilang at maliit na sample, habang binabasa ng dashboard ng Quick Sight ang parehong Aurora data store para makita ang lahat ng finding. Kabilang sa finding ang teksto ng sugnay, mga nakuha at inaasahang halaga, bersiyon ng tuntunin, at sipi. Mga katangian ito ng disenyo ng sample ng AWS, hindi pahayag na pinatakbo ng BIG CHANGE o hiwalay na napatunayan ang mga resulta nito.

Sinasaklaw ng resibo ang napiling populasyon. Hindi nito maipapakita kung kasama sa imbentaryo ng source data ang bawat lease, kung nakuha nang tama ang bawat mahalagang sugnay, o kung naaayon sa kasalukuyang batas ang isang tuntunin. Nangangailangan ang mga iyon ng magkakahiwalay na pagtutugma, pagsusuri sa pagkuha ng datos, at legal na pag-apruba. Kung hindi tiyak kung ano ang saklaw ng “lahat ng lease sa Texas,” maaari pa ring tumukoy sa maling hanay ang eksaktong bilang.

Ang kailangan mong buuin

Inilalagay ng sample architecture ang Quick chat agent sa harap ng MCP server sa AWS Lambda. Nagbibigay ang Amazon Cognito ng service token; sinusuri ito ng API Gateway. Nagbabasa at nagsusulat ang Lambda sa Aurora Serverless v2 sa pamamagitan ng RDS Data API. Ina-access ng Quick Sight ang parehong database gamit ang koneksiyon sa VPC. Nakareserba ang mga embedding ng Bedrock at language model para sa pang-eksplorasyong tool sa paghahanap ng sugnay ng AWS; nananatiling deterministiko ang opisyal na sweep.

May sintetikong koleksiyon na 50,000 lease ang inilathalang halimbawa, kasama ang bersiyonadong rulebook at acceptance script na, ayon sa AWS, ay nagpapatakbo ng 28 pagsusuri sa isang naka-deploy na stack. Tahasang nagbabala ang repository nito na hindi handa para sa production ang code, inimbento ang legal na nilalaman, at kailangan pang sumailalim sa karagdagang security testing at hiwalay na legal na pagpapatunay ang totoong datos ng tenant. Sinuri namin ang dokumentasyon at paglalarawan ng repository; hindi namin ini-deploy ang stack, pinatakbo ang mga pagsusuring iyon, o sinubukan ang routing ng tool ng chat agent.

Upang iangkop ito, itatag muna ang mapagkakatiwalaang imbentaryo ng mga rekord at eksaktong tuntunin kung alin ang kabilang sa populasyon. Pagkatapos, pagpasyahan kung aling mga field ang maaasahang makukuha, aling paghahambing ng tuntunin ang tunay na mekanikal, at sino ang mag-aapruba sa bawat bersiyon ng tuntunin. Panatilihin ang source text, status ng pagkuha, bersiyon ng tuntunin, operator, mga pinaghambing na halaga, petsa, at finding ID upang mabuo muli ng tagasuri ang resulta. Itugma ang resibo sa imbentaryo sa labas ng tugon sa chat. Mga pagsusuri ito sa disenyo batay sa mga ipinahayag na garantiya at limitasyon ng sample, hindi mga hakbang na sinubukan namin.

Ayon sa AWS, tinutukoy ng token ng Cognito client credentials ang Quick application, hindi ang taong nagtatanong sa chat. Umaasa ang sample sa pagtutugma ng sweep ID at oras sa audit layer ng Quick upang matukoy ang user; iminumungkahi ng AWS na ipasa at itago ang end-user ID kung kailangang itala ng mismong compliance store ang pagkakakilanlang iyon. Dapat pagpasyahan ng team ang disenyong ito bago mag-deploy kung kailangan nitong magsilbing hiwalay na audit record ang bawat finding.

Access, mga limitasyon, at gastos

Ipinapalagay sa walkthrough ng AWS na mayroon kang AWS account, naka-configure na kredensiyal para sa AWS CLI v2, Python, at Node 24 para sa CDK, access sa model sa us-east-1, at kapaligiran ng Amazon Quick na may MCP connector at Quick Sight. Python 3.12 ang binabanggit sa post; Python 3.9 o mas bago naman sa naka-link na README. Tingnan ang kasalukuyang mga kailangan ng repository sa pagpili ng lokal na kapaligiran. Naka-pin sa 2.261.0 ang CDK CLI sa mga tagubilin ng sample, ngunit dependency pin iyon ng sample, hindi pangkalahatang kinakailangan ng AWS.

Itinatakda ng kasalukuyang gabay sa Quick MCP ang nakapirming 60-segundong timeout para sa bawat operation, pinakamaraming 100 tool bawat koneksiyon ng server, at hindi pagpapadala ng custom HTTP header. Dapat subukan ang timeout na iyon sa workload ng malaking sweep; kahit tama ang matagal na database job, hindi pa rin ito matatapos bilang synchronous na Quick operation kung lalampas ito sa limitasyon ng connector. Ayon sa gabay, maaaring i-update ang listahan ng tool ng custom connector sa pamamagitan ng Sync. Sa halip, ipinapayo ng AWS blog at README ng sample sa mga user na burahin at muling likhain ang integration kapag nagbago ang mga tool. Sundin ang kasalukuyang dokumentasyon ng Quick para sa connector at tiyakin sa sarili mong kapaligiran ang nakarehistrong listahan ng tool at routing.

Multi-service ang build na ito kaya walang matibay na iisang “presyo bawat sweep” sa inilathalang materyal. Pinaghihiwalay ng AWS ang mga termino ng subscription at agent-hour sa pahina ng pagpepresyo ng Quick at inililista rito ang dagdag na singil ng Quick Sight para sa ilang kakayahan. Nakadepende naman ang pagpepresyo ng Aurora sa kapasidad, storage, at I/O configuration; pinananatiling aktibo ng sample ang minimum na 0.5 ACU sa halip na mag-pause sa zero. Kailangan ding tantiyahin ang workload para sa API Gateway, Lambda, at anumang pang-eksplorasyong tawag sa Bedrock. Iminumungkahi ng repository na sirain ang stack pagkatapos ng pagsusuri upang maiwasan ang tuloy-tuloy na singil. Walang AWS resource na ginawa para sa artikulong ito.

Checklist para sa pagpapasya

Gamitin lamang ang pattern kapag nasasagot ng team ang mga tanong na ito gamit ang sarili nitong datos at kontrol:

  • Maaari mo bang isa-isahin ang buong populasyon gamit ang nirepaso at matatag na predicate at itugma ito sa mapagkakatiwalaang imbentaryo?
  • Mga mekanikal na paghahambing ba ang mga tuntunin, na may mga inaprubahang bersiyon, petsa ng bisa, at sipi? Aling mga kaso ang dapat manatiling malabo para masuri ng tao?
  • Mabibilang ba ang mga pagkabigo sa pagkuha at mga dokumentong hindi mabasa sa halip na tahimik na alisin ang mga ito?
  • Nananatili ba sa bawat finding ang source clause, mga pinaghambing na halaga, at bersiyon ng tuntunin, at makukuha mo ba ang kumpletong hanay ng ebidensiya sa labas ng chat?
  • Matatapos ba ang sweep sa loob ng timeout ng operation ng Quick, at paano mo matutunton ang resulta sa taong humiling nito?
  • Natantiya na ba ng team ang singil sa subscription, database, at mga serbisyo para sa inaasahang dami, at nasubukan na ba ang performance at kalidad ng resulta gamit ang pinahihintulutang datos?

Kung nangangailangan ang gawain ng legal na interpretasyon o paghatol sa isang bukas na pamantayan, maaaring itago ng deterministikong label na pasado o bagsak ang mismong pasyang kailangan ng tao. Kung mga halimbawang kumakatawan sa datos ang kailangan ng team, mas simple ang semantic retrieval. Kung nagsisilbi na sa mga may pananagutang user ang nirepasong rules engine at dashboard, opsyonal ang conversational layer. Hango ang mga alternatibong ito sa sariling talakayan ng post ng AWS tungkol sa “maling pagpili” at sa mga limitasyon ng sintetikong sample nito.

Mga sanggunian at karagdagang babasahin