前一篇我們談過，AI Agent 放進旅宿門禁時，不應該被設計成「客人說一句話，門就直接打開」。門禁不是客服回覆，它牽涉身份、房號、時間、付款狀態、可通行區域與現場安全。真正值得做的，是把 AI Agent 放在任務治理層：它讀懂需求、補齊資料、套用規則，再把權限交給 PMS、Kiosk、發卡機、邊緣設備與門禁系統執行。
這一篇更進一步看：當 Agent 真的開始管理權限，後台要怎麼設計審核、撤回與稽核紀錄？因為旅宿現場最常發生的不是標準入住，而是各種「能不能幫我一下」的例外。
Agent 的第一步，是把一句話變成任務卡
假設櫃台說：「幫 303 房客人多開一張房卡，到明天中午退房前有效。」這句話對人來說很自然，對系統來說卻至少包含五個欄位：房號、旅客身份、權限類型、有效時間、核准依據。
好的 AI Agent 應該先把需求整理成任務卡，而不是立刻執行。任務卡裡要清楚寫出誰提出、對應哪筆訂單、要開通哪些區域、何時開始、何時結束、是否需要主管確認。這一步看似瑣碎，卻是 AI 從聊天工具變成營運工具的分水嶺。
OpenAI 對 agent 工具的描述也強調，Agent 的重點不只是回答，而是能理解任務、使用工具、在流程裡完成動作。放到旅宿場景，這些工具就會是 PMS API、權限規則、門禁設備與現場紀錄。
不是所有權限都該自動通過
旅宿可以先把門禁任務分成三種等級。第一種是低風險標準任務，例如已完成付款與 pre check-in 的旅客，到現場取第一張房卡。這類任務可以高度自動化，由 Kiosk 或邊緣設備在規則內完成。
第二種是中風險例外任務，例如補發房卡、延遲退房、同行者臨時增加、房務臨時進房。這類任務可以由 Agent 整理資料，但要讓櫃台或主管按下確認。
第三種是高風險任務，例如開通非住房區域、跨館權限、解除停權、付款異常但仍要求進房。這類任務不該交給 AI 自動決定，而應該轉人工流程，必要時留下原因與批准者。
這樣的分級，能讓 AI 不會變成黑盒子。它可以加速整理，但不會把安全責任藏起來。
撤回權限，比發放權限更重要
很多智慧入住系統會把焦點放在「多快發卡、多快開門」，但真正的門禁治理，還要問另一個問題：權限能不能被快速撤回？
旅宿每天都會遇到狀態改變。旅客提前退房、換房、付款失敗、遺失房卡、同行者取消、清潔人員完成任務後不再需要進房。只要權限發出去後不能被清楚撤回，系統就會留下看不見的風險。
所以 AI Agent 建立任務時，應該同時建立撤回條件。它不只是「開通 303 房門到明天中午」，而是「若 PMS 顯示退房完成、換房成立、付款未完成或人工撤回，就同步取消這組權限」。這才是真正適合旅宿現場的自動化。
稽核紀錄要讓夜班和管理者看得懂
門禁紀錄不能只是一串技術 log。對旅宿現場來說，紀錄要能回答幾個很實際的問題：誰申請？為什麼申請？誰批准？哪台設備執行？旅客是否真的使用？是否已經失效？
如果夜班接手時只能看到「權限已更新」，其實沒有幫助。更好的後台應該像營運時間線：22:10 櫃台建立補卡任務，22:11 Agent 比對 PMS 訂單，22:12 主管批准，22:13 Kiosk 發卡，22:14 門禁第一次使用，隔日 12:00 自動失效。
這樣的紀錄不是為了增加管理負擔，而是讓現場交接更安心。當有問題發生時，大家不用憑記憶追查。
Agent 應該在任務層，不該直接控制門
旅宿 AI Agent 最理想的位置，是站在「人」與「系統」之間，負責把自然語言需求轉成可執行任務。真正的執行層仍然應該由 PMS、邊緣設備、發卡機、門禁控制器與權限規則負責。
這樣設計的好處，是系統會比較穩。Agent 可以聰明，但不需要擁有最高權限；它可以幫忙判斷，也可以把高風險任務轉給人；它可以追蹤流程，但每一步都留下紀錄。
未來旅宿的智慧化，不會只是多一個聊天框。真正有價值的 AI，是讓例外不再靠紙條、口頭交接和人腦記憶，而是變成可審核、可撤回、可追蹤的任務。對旅客來說，體驗會更順；對管理者來說，風險會更清楚。