Fractional AI Product Manager · Denver, CO

Hire an AI product manager in Denver.

Colorado companies building AI products face constraints that most product managers have not encountered. Colorado SB205 creates documentation obligations for high-impact AI systems. Cannabis companies need AI features that comply with MED advertising restrictions. Energy companies need AI features for field operations that work in low-connectivity environments and account for safety-critical contexts.

Ibotta, Zayo Group, and Evolent Health are building AI features in Denver with these constraints. A fractional AI PM scopes the features with the regulatory requirements built into the spec from the first draft, not added after legal review flags them.

Fixed engagement, fixed scope, quoted after the discovery call. Regulatory constraints are in scope from day one.

How we work

Tell us about your Colorado AI feature requirement.

The Denver regulatory product context.

Colorado passed SB205 in 2024, making it the first state with a comprehensive AI consumer protection law effective February 2026. Companies deploying high-risk AI systems to Colorado residents in employment, financial services, healthcare, insurance, or housing must complete an annual impact assessment. The impact assessment is a product document that describes intended use, known risks, training data, and bias testing results. It is not a legal filing. The PM writes it, not the legal team.

Companies that discover SB205 applies to them after they have built the AI feature face a harder documentation problem. The intended use and training data documentation are easiest to produce before the feature is finalized. After launch, the training data vintage and the model architecture decisions may be difficult to reconstruct accurately.

Denver's regulated industries: cannabis, energy, and healthcare, add product constraints that require specific knowledge. Cannabis AI features must navigate MED advertising rules. Energy field operations tools must work in low-connectivity environments. Healthcare vendor tools must meet HIPAA requirements that go beyond standard data handling.

A fractional AI PM who has worked in these contexts writes the regulatory constraints as product requirements rather than flagging them as risks. A constraint that is a product requirement is solved by engineering. A constraint that is a risk is escalated to legal after the product is built.

Cannabis AI features: what the spec must prohibit.

MED advertising restrictions apply to any content a cannabis company distributes. An AI feature that generates content is an advertising channel, whether or not it is labeled as one.

Output category constraints

The spec defines which output categories the AI feature cannot generate. Recommendations that would constitute advertising to under-21 audiences, claims about athletic performance, and licensed retailer references in restricted channels are prohibited outputs, not post-generation filters.

Classifier requirements

Any AI feature that generates consumer-facing content must include a classifier that flags potential MED violations before output reaches the user interface. The spec defines the classifier accuracy threshold and the review workflow for flagged outputs.

Audit log specification

Every output filtered by the MED compliance classifier is logged with the content category, the rule triggered, and the timestamp. The audit log supports both internal compliance review and potential MED inquiry responses.

Age-gating documentation

For any AI feature that generates content reaching a consumer audience, the spec documents the age verification or audience validation mechanism and the evidence that the 71.6% over-21 threshold is met for each distribution channel.

Energy: safety-critical AI product specifications.

Zayo Group and Colorado's energy sector companies use AI features for field operations, routing, and network management. These are not consumer software contexts. An AI feature that routes a field technician to the wrong site or provides an incorrect equipment status has safety implications. The product spec must be written accordingly.

Safety-critical AI product specs require a hazard log: an enumeration of every scenario where an incorrect AI output could cause harm. Each hazard entry includes the scenario, the severity of harm, the probability of occurrence, and the risk control implemented. This is a design artifact, not a post-launch retrospective. It is written before engineering starts.

Field operations in Colorado frequently involve low-connectivity environments: rural network coverage gaps, underground infrastructure, and terrain that interrupts signal. An AI feature that requires continuous connectivity will fail in these conditions. The spec must define degradation modes: what the feature does at each connectivity level, how it communicates degradation to the field operator, and how it syncs when connectivity is restored.

The safe-state definition is the most important section in a safety-critical spec. It defines what the system does when it cannot produce a reliable output. The answer is always some form of human-decision mode. The spec states this explicitly, and engineering builds it as a first-class feature, not an edge case fallback.

How we work.

Regulatory context scoped at discovery

The discovery call identifies which regulations apply to the feature before the scope is written. SB205, MED restrictions, HIPAA, and safety standards are part of the scope, not discovered mid-engagement.

Constraints as requirements, not risks

Regulatory constraints are written into the spec as functional requirements. Engineering builds to them. Legal does not review the feature after it ships and flag things that were visible from the start.

Fixed scope before work starts

Written scope and fixed price after the discovery call. The scope accounts for the regulatory complexity visible at that point. Change orders for genuinely new information, not for constraints that were knowable.

Questions from Denver product and compliance teams.

What does Colorado SB205 require for a high-impact AI system, and does a B2C AI feature qualify?: Colorado SB205, effective February 2026, applies to developers and deployers of high-risk AI systems used in consequential decisions affecting Colorado residents in employment, education, financial services, essential government services, healthcare, housing, insurance, or legal services. A B2C AI feature qualifies as high-risk if it makes or substantially influences one of those consequential decisions. An AI feature that recommends insurance premiums, employment screening criteria, or loan terms for Colorado residents is covered. An AI recommendation feature for an e-commerce product catalog is not. For covered systems, deployers must complete an annual impact assessment documenting the intended use, known risks, training data, performance metrics, and bias testing results. The impact assessment is a product document written by the PM, not a legal filing written by attorneys. An Ibotta AI feature that influences retailer credit terms for Colorado merchants would likely be covered. A Zayo bandwidth recommendation tool for enterprise customers is less clear and requires an analysis.
How do you spec a cannabis AI feature so it does not violate MED advertising restrictions?: Colorado Marijuana Enforcement Division advertising rules restrict cannabis advertising to platforms where at least 71.6% of the audience is 21 or older, prohibit content that depicts cannabis use as enhancing athletic performance, and ban marketing to minors through imagery or language. An AI feature for a cannabis company must include explicit constraints on its output categories. A product recommendation AI must not generate recommendations that would constitute advertising in restricted channels. A content generation AI must have a classifier that flags output violating MED prohibitions before it reaches a user-facing interface. The spec defines these constraints as functional requirements: the AI must not generate content in category X, and the product must maintain an audit log of every output that was filtered and the rule it violated. Writing these constraints into the spec means engineering builds them in. Writing them after launch means retrofitting content filters into a production system, which typically takes two to three times as long.
What does safety-critical AI mean in a product spec context. What additional documentation is required?: A safety-critical AI feature is one where an incorrect output can cause physical harm to a person. Energy field operations tools, industrial equipment scheduling features, and utility routing systems are examples. The additional documentation required falls into four categories. First, the hazard log: an enumeration of every scenario where an incorrect AI output could cause harm, with the severity and probability of each. Second, the safety requirements: explicit product requirements derived from the hazard log. Each hazard must have a corresponding requirement that addresses it. Third, the safe-state definition: what the system does when it cannot produce a reliable output. For a field operations tool, the safe state is typically a human-decision mode where the AI provides no recommendation and the operator acts on their own judgment. Fourth, the safety case: a structured argument, referencing the hazard log and the safety requirements, that the product is safe enough to deploy in the intended operating environment. Evolent Health's clinical tools and energy sector field operations tools both produce this documentation before release, not after an incident.
How do you spec an AI feature for a low-connectivity field environment that degrades gracefully?: Graceful degradation for a low-connectivity field AI feature requires four spec elements. First, the connectivity assumption: the spec explicitly states the minimum connection quality the full AI feature requires and the expected connection quality in the deployment environment. If those two numbers differ, the spec is incomplete. Second, the degradation modes: a tiered description of what the feature does at each connection quality level. At full connectivity: full AI output. At intermittent connectivity: cached recommendations with a visible staleness indicator showing the age of the last model refresh. At no connectivity: a manual mode where the operator enters and acts on information without AI assistance. Third, the sync protocol: how the device reconciles with the server when connectivity is restored, what data is prioritized, and how conflicts are resolved if the operator made decisions in offline mode that conflict with what the model would have recommended. Fourth, the failure indicator: a UI element that clearly communicates the current degradation mode to the field operator. An operator who does not know they are operating in offline mode may treat cached recommendations as current recommendations. That is a design failure, not a connectivity failure.

Scope your Colorado AI feature.

Describe the feature and the regulatory context you are working in. We reply within one business day.

Hire an AI product manager in Denver.

Fixed engagement, fixed scope, quoted after the discovery call. Regulatory constraints are in scope from day one.

The Denver regulatory product context.

Cannabis AI features: what the spec must prohibit.

MED advertising restrictions apply to any content a cannabis company distributes. An AI feature that generates content is an advertising channel, whether or not it is labeled as one.

Output category constraints

Classifier requirements

Audit log specification

Age-gating documentation

Energy: safety-critical AI product specifications.

How we work.

Regulatory context scoped at discovery

Constraints as requirements, not risks

Fixed scope before work starts

Questions from Denver product and compliance teams.

What does Colorado SB205 require for a high-impact AI system, and does a B2C AI feature qualify?

Colorado SB205, effective February 2026, applies to developers and deployers of high-risk AI systems used in consequential decisions affecting Colorado residents in employment, education, financial services, essential government services, healthcare, housing, insurance, or legal services. A B2C AI feature qualifies as high-risk if it makes or substantially influences one of those consequential decisions. An AI feature that recommends insurance premiums, employment screening criteria, or loan terms for Colorado residents is covered. An AI recommendation feature for an e-commerce product catalog is not. For covered systems, deployers must complete an annual impact assessment documenting the intended use, known risks, training data, performance metrics, and bias testing results. The impact assessment is a product document written by the PM, not a legal filing written by attorneys. An Ibotta AI feature that influences retailer credit terms for Colorado merchants would likely be covered. A Zayo bandwidth recommendation tool for enterprise customers is less clear and requires an analysis.

How do you spec a cannabis AI feature so it does not violate MED advertising restrictions?

Colorado Marijuana Enforcement Division advertising rules restrict cannabis advertising to platforms where at least 71.6% of the audience is 21 or older, prohibit content that depicts cannabis use as enhancing athletic performance, and ban marketing to minors through imagery or language. An AI feature for a cannabis company must include explicit constraints on its output categories. A product recommendation AI must not generate recommendations that would constitute advertising in restricted channels. A content generation AI must have a classifier that flags output violating MED prohibitions before it reaches a user-facing interface. The spec defines these constraints as functional requirements: the AI must not generate content in category X, and the product must maintain an audit log of every output that was filtered and the rule it violated. Writing these constraints into the spec means engineering builds them in. Writing them after launch means retrofitting content filters into a production system, which typically takes two to three times as long.

What does safety-critical AI mean in a product spec context. What additional documentation is required?

A safety-critical AI feature is one where an incorrect output can cause physical harm to a person. Energy field operations tools, industrial equipment scheduling features, and utility routing systems are examples. The additional documentation required falls into four categories. First, the hazard log: an enumeration of every scenario where an incorrect AI output could cause harm, with the severity and probability of each. Second, the safety requirements: explicit product requirements derived from the hazard log. Each hazard must have a corresponding requirement that addresses it. Third, the safe-state definition: what the system does when it cannot produce a reliable output. For a field operations tool, the safe state is typically a human-decision mode where the AI provides no recommendation and the operator acts on their own judgment. Fourth, the safety case: a structured argument, referencing the hazard log and the safety requirements, that the product is safe enough to deploy in the intended operating environment. Evolent Health's clinical tools and energy sector field operations tools both produce this documentation before release, not after an incident.

How do you spec an AI feature for a low-connectivity field environment that degrades gracefully?

Graceful degradation for a low-connectivity field AI feature requires four spec elements. First, the connectivity assumption: the spec explicitly states the minimum connection quality the full AI feature requires and the expected connection quality in the deployment environment. If those two numbers differ, the spec is incomplete. Second, the degradation modes: a tiered description of what the feature does at each connection quality level. At full connectivity: full AI output. At intermittent connectivity: cached recommendations with a visible staleness indicator showing the age of the last model refresh. At no connectivity: a manual mode where the operator enters and acts on information without AI assistance. Third, the sync protocol: how the device reconciles with the server when connectivity is restored, what data is prioritized, and how conflicts are resolved if the operator made decisions in offline mode that conflict with what the model would have recommended. Fourth, the failure indicator: a UI element that clearly communicates the current degradation mode to the field operator. An operator who does not know they are operating in offline mode may treat cached recommendations as current recommendations. That is a design failure, not a connectivity failure.

Scope your Colorado AI feature.

Describe the feature and the regulatory context you are working in. We reply within one business day.