Not with a rules engine. Governance applied to an unmapped landscape is governance applied to a fantasy, and most organizations genuinely cannot see their own APIs.
Start by mapping two landscapes. The technical one: what APIs exist, where they run, what contracts describe them, who calls them. And the people one: who owns each API, who decides, who is affected, who would have to change their habits for any of this to stick. The second map is the one governance programs skip and the one that determines whether they survive.
Then start ridiculously small. Pick three to five things everyone already agrees on — every API has a valid OpenAPI, every API declares a security scheme, every operation has a description, paths use one consistent casing. Automate exactly those, in a pull request check, where the feedback is immediate and the fix is obvious. Nobody argues about those rules, so you get the machinery and the habit in place before you get to the contested questions.
And start with a team rather than the enterprise. A single team that adopts governance and visibly benefits is a far better argument than a mandate from a committee. Governance that starts as an enterprise program tends to be experienced as something done to people. Governance that starts on a team and spreads is something people opt into.
