We keep running into a shadow-IT problem with employee-built workflow tools. Someone creates a useful prototype, gives a polished demo, and stakeholders quickly assume it is ready for company-wide use. The problem usually appears later, when the tool becomes business-critical but the original builder leaves. At that point, multiple teams may depend on it, while nobody has proper documentation, credential access, or a maintenance plan. For sysadmins handling internal tool intake, what minimum requirements do you enforce for access control, credential storage, logging, documentation, infrastructure, updates, and technical ownership before approving one of these apps for production?
3 Answers
My basic checklist would be: confirm that it actually works, document the design and operating procedures, verify that the running system matches the documentation, identify all required infrastructure and dependencies, define and test an update or upgrade process, and review the implementation against the company’s security standards. I’d also require named technical and business owners before launch.
Use one intake and review process for every application, regardless of whether it was built with AI, developed internally, or purchased as a SaaS or commercial product. Classify it based on factors like the data it handles, whether it is externally accessible, and how business-critical it is. Then require controls appropriate to that risk level, including access management, secrets storage, audit logging, backups, and an assigned owner.
A useful tool should be treated like any other production application, not given a special pass because it started as a quick experiment. Before release, I’d want source-code access, deployment instructions, an inventory of credentials and integrations, least-privilege access controls, centralized logs, backup and recovery expectations, monitoring, and a support or succession plan. If nobody with appropriate development experience can maintain it and document the code, it should remain a prototype.
That ownership requirement is the part people often skip. A named builder is not enough unless someone else can access the code, understand the deployment, and take over when that person moves on.