A 30-day AI governance program will not solve every policy question, but it can replace uncertainty with an operating rhythm. The goal is not perfection. The goal is to know what exists, decide what needs review, stop the highest-risk gaps, and create evidence that the program is working.
The mistake is starting with a large policy project before building the basic machinery. Policy matters, but teams need a way to identify AI systems, classify risk, route approvals, and record proof. Start there.
Days 1 to 7: create the inventory
Begin with discovery. Pull from repositories, cloud logs, expense records, vendor lists, product roadmaps, security questionnaires, and team interviews. Ask simple questions: where is AI being used, who owns it, what does it do, what data does it touch, and can it take action?
Do not wait for a complete inventory before moving. Mark unknowns clearly. A system with an unknown owner, unknown data access, or unknown autonomy should become a follow-up item. Visibility is the first control.
Days 8 to 14: define risk tiers
Create a practical risk model. Use factors such as autonomy, data sensitivity, external exposure, impact on people, regulated function, production status, and tool access. Keep the tiers clear enough that product and engineering teams can apply them without a lawyer in every meeting.
For example, low-risk systems may be internal drafting tools with no sensitive data and no action-taking authority. Higher-risk systems may influence customer outcomes, access personal data, or operate with limited human review.
Days 15 to 21: set approval paths and minimum controls
Define what each risk tier requires before launch. Low-risk systems may need owner attestation and basic logging. Medium-risk systems may need security and privacy review. High-risk systems may need legal, compliance, security, product, and executive approval.
Set minimum controls for agents: owner, purpose, tool list, data classification, human approval for sensitive actions, monitoring, incident path, and change review. These controls create a baseline while the program matures.
Days 22 to 30: test the program on real systems
Pick a handful of active AI systems and run them through the process. Do not choose only easy examples. Include at least one agent, one vendor AI use case, one product feature, and one internal tool. The pilot will expose unclear questions, missing owners, and control gaps.
End the month with a first evidence package: inventory records, classification decisions, approval history, control mapping, open issues, and a remediation plan. This package is more valuable than a polished policy that no system has used.
A strong first month should leave the organization with a working loop: discover systems, classify them, approve them, control them, monitor them, and keep evidence. Everything after that is refinement.