Open-source contribution rests on an assertion. Under the Developer Certificate of Origin and its equivalents, a contributor states that they wrote the contribution, or that they have the right to submit it under the project's licence. Nobody verifies this. The system works because the assertion is easy to make honestly and carries reputational weight.
Model-assisted contribution puts pressure on both halves. Did the contributor write it? Partly, in a sense that resists precise statement. Do they have the right to submit it under the licence? That depends on questions about training data and output that are unresolved in most jurisdictions and are being litigated in several.
Why disclosure rules are hard to mean
The obvious response is to require disclosure of model assistance. The difficulty is the boundary. Autocomplete has been model-driven in mainstream editors for years. A developer who accepted a suggested completion has used a model. One who asked a model to draft a function has too. One who asked a question and then wrote their own code has, in some sense, as well.
A disclosure rule that cannot be defined at the boundary is unenforceable, and an unenforceable rule creates a distinction between contributors who interpret it conservatively and those who do not — the opposite of what it was meant to achieve. Projects that have thought about this tend to conclude that a rule here is a statement of norms rather than a control, which is a legitimate thing for a rule to be, provided everyone knows that is what it is.
What flows downstream
Every organisation running open-source software inherits the provenance assumptions of the projects it depends on, generally without knowing what those assumptions are. If a project accepts model-assisted contributions without disclosure, its downstream consumers have accepted that too, and their software bill of materials will not record it.
For organisations with meaningful intellectual-property exposure, the practical step is to establish the contribution policies of the projects that matter most to them. There will be fewer than expected that have one at all.
Fragmentation is the likely outcome
Different projects will reach different answers, weighted by their governance culture, their contributor base and their legal exposure. That is healthy for the ecosystem and unhelpful for anyone trying to make a general assurance statement about their dependency tree.
The useful artefact would be a machine-readable declaration of a project's contribution policy, so that the position could at least be inspected rather than assumed. Nothing of the kind is standardised, and it is the sort of gap that gets filled only after it causes a visible problem.