Many IAM and IGA projects begin with a reasonable ambition: meet every business requirement. When each request is translated straight into a technical solution, the result is an environment that costs a lot to run and resists change. The reasons are familiar: Some requirements get solved inside IAM although they belong somewhere else, and decisions are made without anyone weighing lifecycle cost, operational effort or real business value. The people who will run the solution afterwards are rarely in the room.
What has changed is the price of building: Custom code used to be slow and expensive to produce, and that expense quietly did governance work for us (at least sometimes). It forced a discussion, a budget, an approval. AI-assisted development has removed that hurdle without removing the cost of ownership. Testing across more than 100 language models found that roughly 44 percent of generated code contains a known vulnerability, while refactoring activity has dropped sharply and code duplication sits at record levels. Writing the code was never the expensive part.
This session looks at why organizations end up over-customized, what genuinely changes in the decision now that code is almost "free" to produce, which rules still hold when you bring AI into your Identity Fabric to support it, and how to check the next feature request without a three-week analysis. Two questions settle most cases: where does this requirement actually belong, and who owns the result five years from now?
